Disable JobHosting workers for disabled jobs

[mikaelweave]

Description

• Adds method to disable JobHosting queues for export and import if they are disabled or have no storage account configured.

Related issues

AB#134785

Testing

• Added tests
• Debugged during startup to confirm behavior.

FHIR Team Checklist

• Update the title of the PR to be succinct and less than 65 characters
• Add a milestone to the PR for the sprint that it is merged (i.e. add S47)
• Tag the PR with the type of update: Bug, Build, Dependencies, Enhancement, New-Feature or Documentation
• Tag the PR with Open source, Azure API for FHIR (CosmosDB or common code) or Azure Healthcare APIs (SQL or common code) to specify where this change is intended to be released.
• Tag the PR with Schema Version backward compatible or Schema Version backward incompatible or Schema Version unchanged if this adds or updates Sql script which is/is not backward compatible with the code.
• CI is green before merge
• Review squash-merge requirements

Semver Change (docs)

Patch|Skip|Feature|Breaking (reason)

[brendankowitz]

Maybe a silly question, why do we add them then remove instead of skipping to add?

[mikaelweave]

I thought the same thing initially. 😆 The main reasoning is this approach allows default configuration applied in appsettings.json which is parsed to the configuration objects. I think this is the correct approach vs applying overrides via environment variables/appsettings overrides in the hosting environment which have to be maintained separately.

So once we parse the defaults into the configuration class, why have the removal logic here? I'm thinking keeping it in this class encapsulates the logic here vs polluting the registration classes with operation specific logic. It just exposes a hook to be called.

I was on the fence about implementation on this - happy to change the approach if there are thought a different direction.

[mikaelweave]

@brendankowitz - I could use a custom ConfigurationProvider instead like below. Thoughts?? I think this would intercept the configuration of the class.

fhir-server/src/Microsoft.Health.Fhir.Api/Features/Binders/DictionaryExpansionConfigurationProvider.cs

Line 22 in cb53a35

public class DictionaryExpansionConfigurationProvider : ConfigurationProvider

[brendankowitz]

In thinking about it, perhaps this is calling more to consolidate these settings into one place. Right now we enable/disable in one place, configure job settings in another and remove as a post step. It might make more sense to move all these into a single config which would make this more discoverable / maintainable