[dbx-num] add state machine to 526

[SamStuckey]

Summary

NOTE: this is PR 3 of 3 to add this logic

• PR 1
• PR 2

The Problem

We are about to do an audit in cooperation with VBMS to determine the success of our past year of remediation efforts. Though VBMS is the source of truth, we need a way to easily mark submissions as conceptually 'done' or 'off our plate'.

To date, we have been using the presence of submitted_claim_id and backup_submitted_claim_id to represent success via the primary or backup submission path, respectively.

This did not account for our 'failsafe' remediations

Additionally, with a simple state machine in place we have a way to record the results of Lighthouse's status updates. Even after we send a submission to lighthouse, it isn't "off our plate" until LH has marked it as successful (status of vbms).

The solution

• Add a basic state machine to the form 526 Submission flow with pass fail states for VBMS and remediation
• Add other transitory states for completeness

Other stuff

• add state changes everywhere it's applicable in our current code. This covers only a few of the available states, as it will take a while to backfill states (as part of our audit) and to implement our status polling (will inform state transitions).

Omissions

This work does not add any transition validation to the state machine. That would be out of scope for MVP, and dangerous to roll out as it could cause errors in the submission flow. MVP is to simply add the datapoint, unblocking our audit of VBMS.

Related issue(s)

• Ticket
• Feature / Implementation Documentation

Testing done

• New code is covered by unit tests
• Instantiation of affected objects and testing for continuity

Screenshots

Note: Optional

What areas of the site does it impact?

• Form 526, but not in a veteran facing way. this will be used primarily for remediation of failed submissions, at least for MVP

Acceptance criteria

• I fixed|updated|added unit tests and integration tests for each feature (if applicable).
• No error nor warning in the console.
• Events are being sent to the appropriate logging solution
• Documentation has been updated (link to documentation)
• No sensitive information (i.e. PII/credentials/internal URLs/etc.) is captured in logging, hardcoded, or specs
• Feature/bug has a monitor built into Datadog or Grafana (if applicable)
• If app impacted requires authentication, did you login to a local build and verify all authenticated routes work as expected
• I added a screenshot of the developed feature

Requested Feedback

(OPTIONAL)What should the reviewers know in addition to the above. Is there anything specific you wish the reviewer to assist with. Do you have any concerns with this PR, why?

[freeheeling]

[SamStuckey]

Marking this Ready for review with an outstanding linting error on my test, as I would consider it extraneous. The linting concern is about the stubbing of a method provided by an included module within the object I'm testing. The reason I can't (at least I haven't figured out how to) fix this, is that within_sidekiq_retries_exhausted_block doesn't recognize either the JobTracking module that define the problematic method if or the parent class into which the JobTracking module is composed.

I took a crack at updating our RSpec config to manually include these methods and even that was fruitless. Given that this is existing functionality that has nothing to do with my changes, and stubbing it allows for the testing of one of my use cases by simply not blocking the test from running, I feel like this is probably a fair exception to the rule