feat(sql): add SQL bootstrapper

[paullatzelsperger]

What this PR changes/adds

This PR adds the SqlSchemaBootstrapper class, which allows sql-related extensions to enqueue DDL statements. In the prepare() phase, the bootstrapper then executes these commands one after the other.

To do that, the schema files (formerly known as schema.sql) were renamed and moved to the resources/ folder. The were given individual names to avoid name clashes.

In addition, all SQL-store tests were updated to read the schema from the resource rather than docs/schema.sql.

Why it does that

easy way to create database structures.

Further notes

• "edc.sql.schema.autocreate" is false by default

Linked Issue(s)

Closes #4356

Please be sure to take a look at the contributing guidelines and our etiquette for pull requests.

[codecov-commenter]

⚠️ Please install the to ensure uploads and comments are reliably processed by Codecov.

Codecov Report

Attention: Patch coverage is 83.09859% with 12 lines in your changes missing coverage. Please review.

Project coverage is 74.95%. Comparing base (7f20ba5) to head (ee45e97).
Report is 370 commits behind head on main.

Files	Patch %	Lines
...ne/store/sql/SqlAccessTokenDataStoreExtension.java	0.00%	3 Missing ⚠️
...ataplane/store/sql/SqlDataPlaneStoreExtension.java	0.00%	3 Missing ⚠️
...se/edc/sql/bootstrapper/SqlDmlStatementRunner.java	91.30%	2 Missing ⚠️
...dc/sql/bootstrapper/SqlSchemaBootstrapperImpl.java	80.00%	2 Missing ⚠️
...l/bootstrapper/SqlSchemaBootstrapperExtension.java	92.30%	0 Missing and 1 partial ⚠️
...itor/store/sql/SqlPolicyMonitorStoreExtension.java	0.00%	1 Missing ⚠️

❗ Your organization needs to install the Codecov GitHub app to enable full functionality.

Additional details and impacted files

@@            Coverage Diff             @@
##             main    #4376      +/-   ##
==========================================
+ Coverage   71.74%   74.95%   +3.21%     
==========================================
  Files         919     1071     +152     
  Lines       18457    21468    +3011     
  Branches     1037     1174     +137     
==========================================
+ Hits        13242    16092    +2850     
- Misses       4756     4852      +96     
- Partials      459      524      +65     

☔ View full report in Codecov by Sentry.
📢 Have feedback on the report? Share it here.

[ndr-brt]

this method should be put in the interface (that will save the explicit cast in the SqlSchemaBootstrapperExtension)

[paullatzelsperger]

I don't want this method in the interface, for it could entice contributing modules to invoke it, which could potentially cause problems. The cast is ugly, but it should be possible to simply use the variable (as opposed to the getBootstrapper() method) in the prepare() phase.

[ndr-brt]

ok, I understand it, but this necessity is not explicit (and being misinterpreted, e.g. from a future-me :) ), that could be achieved by keeping only the addStatement method in the bootstrapper and moving the execution logic to a module-private service, that won't be registered on the runtime, this way the executeSql will effectively become not callable from other modules.

[paullatzelsperger]

thats a lot of ceremony for one single method. if executeSql() is package-private and documented, it should be clear enough what is done.
In addition, I didn't put the interface in an SPI package on purpose, because it is not intended as an extension point anyway.

[paullatzelsperger]

I tried it, and it looks OK, but I'm not really sure splitting such a trivial task in two classes (and two test classes) is really worth it TBH. LMK what you think.

[ndr-brt]

at this point the createDatabase could just create the database and leave the bootstrapper to create tables and indexes

[paullatzelsperger]

for the E2E tests this will work but the e2e transfer tests, e.g. TransferPushEndToEndTest, run into a race condition then. I'll give it a shot using @Order(...)