Parse and verify anx at point of POST

[JessicaFrank]

Issue: number and date variable types are being used in text field types. So the restrictions A2J Author puts in place to ensure date and number variable types contain valid dates and numbers aren't being imposed. The text field type doesn't restrict a user's input.

So answer files are being generated that have variables like [Date DA] containing undefined/January 45, 2024/undefined if a user types "January 45, 2024" into a text field with a date variable type underneath it.

Also allowing number variable answers to go into answer file like 5kjbsdloayjanbd90dun

These are causing HotDocs to fail at the point of assembly. LHI has asked us to look into preventing these "invalid" answers from posting to the HD server.

Suggested fix includes validating the entirety of the answer set at the point of the POST (final assemble + save/exit).

Remove all invalid answers/variables from the answer set before it's posted. Retain whatever valid answers are left and pass those on. It's a final gatekeeping check that authors haven't set variables in logic, repeat loops don't allow for abandoned answers in a loop, and the above date/number in a text field issue.

I'll reach out to LHI to ask for any other things that this final check should look out for.

[JessicaFrank]

4 states of variables: 1) Q is never seen due to branching - in the A2J sense, I think this is considered unanswered 2) Q is seen, but not a required answer, so is skipped - this would also be unanswered A2J logic wise 3) Q is seen and bad answer is shoe horned in there due to author mistake or users being users somehow, this is technically answered in the A2J sense, but will break assembly with hotdocs so should be purged at the end 4) Q is seen, answered with good answer that can render in a hotdocs or DAT template correctly and can be left alone (also counts as answered in A2J logic obvs)

The fix for this bug will remove any values for variables in scenario 3 above. The undefined values or any values that are "breaking" will be set to unanswered.

Also at the point of setting them to unanswered, an automated message should be sent to webmaster@a2jauthor.org to capture the interview name/number, date, time, variable that was set to unanswered -- so the CALI team can alert an author that their interview has a bad variable/field match in it and users' answers aren't passing.