Add form variable checks

[ChinHairSaintClair]

Is your feature request related to a problem? Please describe.
Downstream processes pull data from CouchDB and push it through to SQL for reporting. Variable keys are used as column names. If these names exceed the allowed column length or match a reserved word, the process breaks. Because forms contain skip logic, these problematic vars don't come through consistently, which result in intermittent interruptions.

Additionally, a variable length warning could encourage implementers to consider their naming strategies more carefully. While brevity shouldn't come at the cost of losing context, overly verbose or unnecessarily deeply nested vars can also increase maintenance complexity and make referencing them throughout the project config more cumbersome.

Describe the solution you'd like
Reduce downstream issues related to reserved words and variable lengths by introducing limits and restrictions and promote cleaner project config.
I propose introducing the following structure to the form properties:

{
  "var_restrictions": {
    "warn_length": <int>,
    "error_length": <int>,
    "ignore_list": <array>,
    "reserved_list": <array>
  }
}

Their functions:

• warn_length: Print a warning with a list of vars whose length exceeds this limit
• error_length: Throw an error with a list of vars whose length exceeds this limit
• ignore_list: Exclude specified entries from either warning or error checks
• reserved_list: Throw an error, with list of relevant items, if any reserved entries match form variables.

Describe alternatives you've considered
NA

Additional context
Forum discussion:
https://forum.communityhealthtoolkit.org/t/form-variable-length-name-warning/5541

[jkuester]

Sorry, @ChinHairSaintClair, I missed that forum post. 😓 Out of curiosity, what configuration are you planning to use for these restrictions? I am just wondering if we should just bake some of this into cht-conf without bothering to make it configurable... 🤔

[ChinHairSaintClair]

All good @jkuester 🙂 . We could definitely define some sensible defaults in the tool itself, I just also think this is one of those cases where some level of configurability is important. Constraints aren't uniform across forms, and configuration can differ based on implementation context.

In our case, the thresholds differ quite a bit between contact and app forms. Contact forms have already been consolidated (create & edit into one) and cleaned up significantly (made easier thanks to separation between what's persisted vs UI), so we can afford to be much stricter with warn/error lengths there.

App forms on the other hand, vary a lot more. Some are large and deeply nested and will take time to bring within stricter limits. While others are smaller or newer and can reasonably be held to tighter constraints from the outset. Having configurable thresholds lets us incrementally improve these.

The reserved words in our case are quite specific to our implementation (e.g influenced by SQL), and that list could evolve over time as our implementation matures. Making that configurable avoids having to keep updating core logic for what is effectively environment-specific behaviour.

Having the option to set restrictions per context lets us enforce stricter rules where we can, while still supporting more complex forms as we gradually bring them in line.

[ChinHairSaintClair]

@jkuester I've added some lenient default var lengths. I rebased, and all checks now pass.