Creates a new model, LighthouseDocumentUpload, responsible for persisiting a record of a document that was submitted to Lighthouse's Benefits Document API. We will use this to track the status of a document as it makes its way through the VA's systems.

Document Uploads must be attached to a Form 526 submission, and if they reference a Veteran-submitted document that was forwarded on to Lighthouse, they must be attached to the FormAttachment record created for that upload as well.

A lighthouse_document_request_id is also required; this is returned from the Lighthouse Benefits Documents API as requestId in their response body. We will need this identifier to track the upload as it passes through Lighthouse's processing, since their status endpoint requires we pass it to look up the status of a document.

Adds an AASM state machine to LighthouseDocumentUpload that accounts for the various potential lifecycle events once a document reaches Lighthouse. Adds transition guards to ensure the proper metadata is stored before making certain transitions (e.g. if there is a failure makes sure we have saved an error_message)

Updates factories for LighthouseDocumentUpload and FormAttachment to support tests

Capture events metadata on LighthouseDocumentUpload state transitions and persist the actual response metadata from the Lighthouse /uploads/status API endpoint

These logs will drive DataDog alert events when there are submission failures

Creates a Plain Old Ruby Object to abstract out the parsing of the complex nested response from the uploads/status endpoint of the Lighthouse Benefits Documents API.

Provides convenience methods for checking whether a document has completed all processing, has failed processing, or has progressed to another step in the process

Begin Update documents status service

Implements a service class that encapsulates all of the parsing of a Lighthouse document status data structure, updates a supplied LighthouseDocumentUpload accordingly

Create table for tracking the status of a Form 526 supplemental document we have uploaded to Lighthouse

Simplifies state tracking and validaitons in the model we use to track Form526 document submissions to Lighthouse

Overhauls the service class for parsing a Lighthouse document status response and updating a Lighthouse526DocumentUpload record accordingly.

Simplifies the API for this class to reflect the simplified infrastructure of the service object that will be using this

Simplifies the UpdateDocumentsStatusService to use the simplified API of the UploadStatusUpdater. Makes the service responsible for passing the Lighthouse response metadata to the updater class, and logging to statsd metrics based on the outcome

Implements the actual job that orchestrates polling of the Lighthouse uploads/status endpoint to get the current status of a document we have uploaded to Lighthouse. Includes Sidekiq retry exhaustion handling

Update service and tests to take Lighthouse benefits response from the job

Freezing development for early draft PR feedback; latest changes:
- Account for documents that have not been polled for updates yet (status_last_polled_at is nil)
- Begin end to end testing using the Lighthouse QA domain (still debugging with Lighthouse)

Couple loose ends to clean up ahead of draft review

Adds live VCR tests with the status polling endpoint using documents provided by Lighthouse in their QA environment.

Makes necessary changes across service components and in tests to reflect bugs that were found when testing with the actual endpoint

Adds logging and a StatsD metric (for alert monitoring) when the call to the status endpoint returns a non 200 response