Split CbvApplicant into three STI subclasses

[tdooner]

Ticket

Related to FFS-2456. Maybe not completely solving the ultimate purpose of that ticket, but I think this will go far enough towards solving it that we can probably close that ticket out until we hit more pain from these agency-specific configurations.

Changes

Split CbvApplicant into three Single-Table Inheritance (STI) subclasses

These subclasses contain the complexity for validating MA/NYC/Sandbox
sites. The base class contains shared functionality. The underlying
cbv_applicants table still contains all the columns for all the
subclasses :-/.

Context for reviewers

Discussed via Slack and it seems like we agree on this approach. So this is mergeable now (2/14 ❤️ ).

Acceptance testing

• No acceptance testing needed
  • This change will not affect the user experience (bugfix, dependency updates, etc.)
• Acceptance testing prior to merge
  • This change can be verified visually via screenshots attached below or by sending a link to a local development environment to the acceptance tester
  • Acceptance testing should be done by design for visual changes, product for behavior/logic changes, or both for changes that impact both.
• Acceptance testing after merge
  • This change is hard to test locally, so we'll test it in the demo environment (deployed automatically after merge.)
  • Make sure to notify the team once this PR is merged so we don't inadvertently deploy the unaccepted change to production. (e.g. :alert: Deploy block! @ffs-eng I just merged PR [#123] and will be doing acceptance testing in demo - please don't deploy until I'm finished!)

[GeorgeCodes19]

So this would be the error that's given for agencies that are not STI? i.e. sandbox?

[tdooner]

Yep, it's the default used when an STI subclass doesn't override it (as cbv_applicant/ma and cbv_applicant/nyc both do.)

[GeorgeCodes19]

Looks good to me. I'm a big fan of this approach.

I can see how things can get a bit confusing with using helper methods such as a agency_translation while having multiple language file entries

 pdf:
          agency_header_name:
            ma: Massachusetts Department of Transitional Assistance
            nyc: NYC Human Resources Administration
            sandbox: CBV Test Agency

But also having the STI convention

cbv_applicant/ma:
          attributes:
            agency_id_number:
              blank: Enter a valid agency ID number.
              invalid_format: Agency ID number must be 7 digits.
            beacon_id:
              invalid_format: Your WELID must be 6 characters. It can only include letters and numbers.
            snap_application_date:
              invalid_date: Enter today's date or the date you contacted the client. This date must be today or in the past year.
        cbv_applicant/nyc:

[allthesignals]

my MDR sense is that this is "scary," but IDk why — it's unusual. Why does it work?

[tdooner]

The Rails i18n gem is mysterious and important. In this case, it's because the validation error message lookup logic is aware of potential STI ancestors and tries multiple different keys until it finds one that matches.

[allthesignals]

ahhh. i see. the inheriting model serializes its name with the slash. fascinating thx

[tdooner]

r.e. @GeorgeCodes19

I can see how things can get a bit confusing with using helper methods such as a agency_translation while having multiple language file entries

Yeah, this is a second pattern for have agency-specific translation overrides. However, we already had this pattern because the snap_application_date helper had different keys for different agencies. I don't love having a second pattern for this, but at least it does match the agencies' attributes pretty cleanly.