Selective creation of OAuth and JavaBatch schemas from fhir-persistence-schema

[lmsurpre]

Is your feature request related to a problem? Please describe.
One of the more advanced features of the IBM FHIR Server is the ability to split multiple tenants (or even multiple datastores within a single tenant) into multiple different backend stores.

However, recently we introduced some features which require a particular schema which is shared across all tenants: OAuth and JavaBatch.

Currently, the fhir-persistence-schema --create-schemas creates all three of these schemas on a single db (in addition to a FHIR_ADMIN schema to manage the tenants and track the version history of all the schemas).
Similarly, the --update-schema action will update all the OAuth and Bulk schemas in addition to the configured FHIRData schema.

This means that we will end up with copies of these tables on each db, even though only a single copy of these will be used (the ones defined in the liberty datasource configs for the javabatch and oauth configs respectively).

Describe the solution you'd like
Today, --create-schemas creates all the schemas.
To support different schemas in different dbs, we'd want to either:
A. change it to --create-schema SCHEMANAME; or
B. drop it and have it happen automatically during --update-schema

Then, in order to support the creation and updating of the OAuth and JavaBatch schemas selectively, I think we should introduce a separate action for each of these:

--update-fhir-schema
--update-oauth-schema
--update-bulk-schema

Further, to drive consistency across these actions and allow maximum flexibility, I think we should remove the --tenant-name argument and instead pass the tenant name as part of each of these three actions:

--update-fhir-schema FHIRDATA
--update-oauth-schema FHIR_OAUTH
--update-bulk-schema FHIR_BATCH

In each case, the FHIR_ADMIN schema can be implicitly created and used to track the version of the tables being deployed for each schema on the currently configured db.

With this design, an administrator that wants to deploy the FHIR_OAUTH and FHIR_BATCH schemas in a separate database from the FHIRDATA schema, could accomplish that with the following steps:

1. configure a properties file (fhirdata.properties) with database information for the db they want to deploy the fhir server schema on
2. configure a different properties file (fhirserver.properties) with database information for the db they want to deploy the OAuth and JavaBatch schemas on
3. run java -jar fhir-persistence-schema-cli.jar --prop-file fhirdata.properties --update-fhir-schema FHIRDATA
4. run java -jar fhir-persistence-schema-cli.jar --prop-file fhirserver.properties --update-oauth-schema FHIR_OAUTH --update-bulk-schema FHIR_BATCH

Whereas an administrator that wants to deploy them all on a single db could just run
java -jar fhir-persistence-schema-cli.jar --prop-file db.properties --update-fhir-schema FHIRDATA --update-oauth-schema FHIR_OAUTH --update-bulk-schema FHIR_BATCH
with a single config file.

Describe alternatives you've considered
One alternative to creating the FHIR_ADMIN schema implicitly on each database would be to have a single "ADMIN" database and have that track all the schemas on all the dbs.

The advantage of this approach is that we could pass the "admin" db info to fhir-persistence-schema and it could create the FHIR_ADMIN, FHIR_OAUTH, and FHIR_BATCH tables in this single spot and use the FHIR_ADMIN schema on this single database to track everything else it does.

That is closer to the "Open service broker" design we used for the internal DSTU2 server.

Additional context
This came up while reviewing #1123 and I collaborated with Albert on the proposed design here.

[prb112]

I just implemented this...