Prepare New BizOps Feature Flags Infrastructure for accept/reject Bundle functionality

[shah]

We need to turn on auto-rejection (not forward errors to SHIN-NY) and set up a new Business Operations (BizOps) Feature Flags infrastructure in our Help Desk. This infrastructure will allow application users to see and modify feature flags, starting with which messages to accept/reject, via a file in a GitHub repo.

• The feature flags file will be in YAML format for easy modification by end users (as opposed to JSON).
• The first file will be located at Help Desk Repo feature-flag/non-sensitive-common.yml.
• All other feature flags will be stored in /feature-flag, with non-sensitive, non-PHI content in non-sensitive-common.yml.

App Strategy:

• Create feature flags encapsulation using the existing Configuration class
• At start of the app, load the configuration for all feature flags
• In the Console menu add new Feature Flags tab to be able to see the flags
  • In the Feature Flags tab allow reloading of file during application run

[shah]

The initial file has been created in Help Desk Repo /feature-flag/non-sensitive-common.yml.

bizOps:
  api:
    fhir:
      bundle:
        contentActions:
          # allow one or more jsonPath-based actions
          - jsonPaths:
              # see https://github.com/json-path/JsonPath for JSONPath expressions
              # the following finds ... "location": [ "Bundle.entry[0].resource/Patient/cc6ce0d9-297d-4166-b264-f7e33db53b67/.meta.lastUpdated"]
              # basically any "location" entry that starts with `Bundle.entry[n].resource/Patient` and ends with `/.meta.lastUpdated` will match
              - "$.location[?(@ =~ /^Bundle\\.entry\\[\\d+\\]\\.resource\\/.*\\.meta\\.lastUpdated$/)]"  
            action:
              nature: "reject"  # might have other natures in the future, for now it's just "reject"
              injectContent: {}  # whatever goes into `inject` is added to the operation outcome, allow Spring template expressions}

[shah]

@raphaelvp @ratheesh-kr I've introduced a new utility class JsonContentAction which you can learn about in hub-prime/src/test/java/lib/aide/JsonContentActionTest.java test case.

JsonContentAction provides a framework for defining rejection rules based on JSONPath expressions and applying transformations to JSON objects using Spring SpEL expressions.

The class supports two main types of transformations:

• Appending objects to arrays.
• Applying key-value pairs to maps.

This is useful in scenarios where you need to reject or modify JSON content based on specific rules, like handling errors or modifying content dynamically.

The class uses a builder pattern to allow chaining multiple rejection rules, and each rule defines a JSONPath condition and a set of transformations to apply when the condition is met.

Please assign this as a high priority task to a senior Java engineer.

• [x] start with learning how to use JsonContentAction in JsonContentActionTest by replacing the following System.out.println in testRejectContentTransformation() with assertions so that the engineer learns how to use the class.

// Switch these to assertions 
System.out.println(appliedJson);
System.out.println(appendedJson);

• [ ] Then, re-implement #465 using JsonContentAction "manually" like this:

  
  final var fhirJCA = new JsonContentAction.Builder()
      .withReject(
              ".location[?(@[0] =~ /Bundle\\.entry\\[\\d+\\]\\.resource\\/Patient\\/.*\\.meta\\.lastUpdated$/)]",
              List.of(new JsonContentAction.AppendObject(
                      JsonPath.compile("$.rejectionsList"), Map.of(
                              "'injectedKey' + '1'", "'Injected value for ' + rule.description() + ' ' + rule.elaboration.e1"))),
              "Forced ", Map.of())
      .build();

final var actionable = fhirJCA.execute(myFhirBundle); // if actionable.rejections().size() is greater than zero, prepare to reject // add an empty list to myFhirBundle to store the rejection // final var updatedBundleWithRejectionMsg = actionable.rejections().get(0).transformed(new HashMap<>(myFhirBundle), Map.of());

- [ ] Then, re-implement #465 by removing all hard-coded Java and allow future expansion using GitHub YAML as the source