FHIR: Investigate splitting assembly

[fhcarter]

At present, we define a single assembly that has myriad configuration properties, mostly to obtain the information we need for various forms of authentication. Since not all properties can be required, they are all optional & we check at run time.

Though code management will be painful, we may want to have separate assemblies for the various authentication types. That's quite ugly, too. In practice, this may be something we wait and determine via demand. That is, leave it as is. If we find that, in practice, it's confusing and/or difficult to support, then we split. Otherwise not.

Placing this issue as a place for somewhat public discussion.

[fhcarter]

Issues with this:

• development may be a pain, but that can probably be ameliorated via gradle tasks.
• Confusing to customers as they have to look thru the catalog to find the fhirConnectionNone vs. fhirConnectionBasic vs. fhirConnectionOauth vs. fhirConnectionSmart vs. fhirConnectionUDAP or something like that. And if things change, uninstall & install a new one. ... Because
• Confusion in code since there will be multiple assemblies that bring in the same service, source, etc. Anyone who tries to install > 1 of these may run into issues. Just not set up for things to work this way.
  • May be ameliorated by some clever renaming of things, but this will all be rather confusing and, potentially, brittle.

[fhcarter]

Other option may be to have a set of layered set of things to install. This tends to confuse people (from experience with the Camel Kamelet-based assemblies), but may prove manageable. But there would be interrelationships that may result in code compilation errors (sources missing, etc.), that will make things look ungainly.