Clarify which schema tool options work together and which ones do not

[lmsurpre]

Is your feature request related to a problem? Please describe. From https://github.com/LinuxForHealth/FHIR/issues/3248#issuecomment-1022199171

I guess my real concern is mostly with managing the many options for the schema tool. Certain flags only work with certain actions. Some actions can be combined and some cannot. I'm not sure how to best document it all, but I think we could do better.

I hit this again recently. I was trying to create a schema, deploy our schema to it, and grant permissions to a user as succinctly as possible.

I found that --grant-to works together with both --create-schemas (and the --create-schema-x variants) as well as with --update-schema (and the --update-schema-x variants), but that the create actions are mutually exclusive with the update actions. Is that intended?

Describe the solution you'd like If we intend there to be a set of commands which are mutually exclusive, I think a more obvious design for that would be to modify the usage to something like java -jar *.jar <action> [--option]. For example:

• java -jar *.jar create-schema-fhir --schema-name fhirdata --grant-to fhiruser
• java -jar *.jar update-schema-fhir --schema-name fhirdata --grant-read-to fhirreaduser
• java -jar *.jar drop-schema-fhir --schema-name fhirdata --confirm-drop

Then, in addition to our top-level usage info (--help), each subcommand could have its own help section that lists just the relevant options to that command:

• java -jar *.jar --help
• java -jar *.jar create-schema-fhir --help
• java -jar *.jar update-schema-fhir --help
• java -jar *.jar drop-schema-fhir --help

Describe alternatives you've considered Keep the current usage pattern and attempt to support all options together. For example:

• java -jar *.jar --schema-name fhirdata --create-schema-fhir --update-schema-fhir --grant-to fhirserver

However, I think this is harder to document and test.

Acceptance Criteria

1. GIVEN [a precondition] AND [another precondition] WHEN [test step] AND [test step] THEN [verification step] AND [verification step]

Additional context The Main has a "process" method with a big if/else block that controls which actions are mutually exclusive (and in which order of precedence).

[punktilious]

In my opinion, it's time we separate the schemas so we only operate on one at a time (using --schema-name to override the default). Introduce one new argument to determine the type of schema we're building (e.g. OAUTH, BULKDATA etc). Then make the remaining arguments operate the same way regardless of the type of schema (principle of orthogonality).

[lmsurpre]

Given that we'd like to retire the OAuth support (and maybe JBatch if we move away from java batch for bulkdata), lets

1. use create-schema for the action instead of create-schema-fhir, then introduce a new flag like --schema-type with options like fhir, jbatch, and oauth, but default to fhir
2. refactor the Main class to check the new schema-type flag and use that value to delegate to some other class for performing the actual action on that schema type