refactor(logic): consolidate logic functions into shared

[justynoh]

Problem

There is currently some tech debt incurred as a result of the angular->react migration that has not yet been cleaned up. In particular, the functions used to evaluate logic have not been refactored from src to shared, because the client-side types for input data differs between angular and react.

As a result, for a period of time, the logic for logic (ha!) had to work over three schemas if they were truly to be shared - server, angular and react. Instead of making this work, we basically duplicated the logic and made the types work for the frontend, while retaining the original backend code in src.

Now that angular is gone, however, it's time to make this code truly shared.

Solution

This PR moves src/shared/utils/logic into shared/utils/logic and adjusts the types to account for existing behavior both on the frontend and backend.

There are no behavioral changes from the current behavior, and we should not expect any cutover period due to desynced fe/be.

Breaking Changes

• No - this PR is backwards compatible

Tests

All tests are regression tests.

• Show fields logic
  • Show fields based on "greater than or equal" to a number/decimal field.
  • Show fields based on "less than or equal" to a number/decimal field.
  • Show fields based on "equal" to a decimal field.
  • Show fields based on "either" for a radio field.
  • Show fields based on "either" for a radio field with "Others" as an option.
• Prevent submit logic: repeat the same tests as above, but preventing submit instead of show fields.

[justynoh]

Also, this was a side quest as a result of tackling backend validation for MRF, which requires these logic functions to work well.

[KenLSM]

this looks iffy... but I can't think of a better solution

[justynoh]

the typechecker needs a lot of help in this case. like you said, I don't really have a good way of doing this other than just guaranteeing at runtime that there is no uncaught case (i.e. guaranteed only by the fact that isNotX(args) is defined to be !isX(args)).

I suppose an alternative is just to like. do a single if-else, and then //@ts-ignore the rest but that feels even more hackish. Having a typeguard, even if self-defined and somewhat weird, is better than having no typeguard at all. I think I might just leave a comment explaining why it's a bit complicated in this case, and that we would rather have the types than not even if it results in strange unreachable code paths that aren't obvious to the typechecker.

[KenLSM]

LGTM! Yay for cleanups