Bootstrapping config on first deployment

[poikilotherm]

This is a story for #5292 and it depends on introduction of Flyway in #5344 / #5349.

---

While installing Dataverse, you need to create a few database entries regarding admin user, root dataverse, roles, metadata blocks and more. Details can be found in setup-all.sh and reference_data.sql.

This is currently done by the install script. This story is about a proposal to change this. Positive sideffect: this could be a first step towards a web based installer as @pdurbin would love to see.

Load initial data after migrations happened

As soon as the database has been created by JPA and Flyway, we can hook a bootstrap loader into the BaseFlywayCallback.afterMigration() routine. Example

After checking that the database has no root dataverse present, it could load the data currently loaded via REST API with internal calls to the appropriate services, based on the same data structures (mostly JSON files).

A switch offers skipping bootstraping from code. It has to be enabled to let bootstrapping happen for maximum backward compatibility.

Benefits from this and things to keep in mind

• Development and Test installations, either Docker or Appserver based might not need to use an installer as long as default values are sufficient.
• Adding a switch via a default false system property allows skipping, so the installer as it is now can stay as is.
• Current setup of metadatablocks via loading from JSON files can be reused.
• Setting things via the API is more future proof than a database dump, as the API is more flexible. Migrations for a fixture seem ineffective.

As always: I would really appreciate comments and input.

[poikilotherm]

Some more explaining context why this came up in the first place:

While hacking on #5292, I missed an easy option to run the setup-all.sh script after the WAR has been deployed. That is not easy to achieve without application support and ideas like an init container or other stuff seemed a rather ugly workaround.

Bootstrapping from within the application was the natural thing to come up with next. This can of course be done independently from Flyway (simple @startup EJB), but it seemed more natural to make this happen AFTER all migrations passed.

[pdurbin]

Closing because we now have configbaker.