[LH Doc Upload Migration] Spike already completed work/plan breaking it up

[NB28VT]

Acceptance Criteria

• Sync on polling implementation status (it should proceed releasing this since polling will be part of this
• Review existing PR Dbex 64564 lighthouse supporting evidence attachment vets-api#13835 that implements full migration
• Draft plan to split up the work
• Sync with mobile team to see if this endpoint has been working for them in production
• Provide an engineering document that describes your approach
• Update the additional tickets in this epic to reflect your final approach

[NB28VT]

Provided this research doc and project outline

[NB28VT]

Feedback from @SamStuckey

• how does changing the document upload endpoint relate to the form submission endpoint? does it matter that one might go to evss and one might go to lighthouse? what about rollbacks?
• "Form 0781/a job should ideally be broken up into two jobs" why?
• "Each job update should be built behind its own Flipper " any cross-job compatabilyt issues? e.g. can BDD go one place and User submitted documents to another?

[NB28VT]

My reply to the feedback in Slack (including here for posterity)

1. According to Emily there is no issue with migrating one and not the other we can still upload documents via EVSS and push the main submission the Lighthouse since they basically go to the same place

2.Ah that's right, this is something I'd have to explain in a call. It came up when I was going to implement a failure mailer to the veteran. As written there was no real clean way to do that. It's not super relevant to the migration. TLDR there are two separate API calls that could happen (one for 0781, one for 0781a) but the failure handler and all of the retry logic is tied to the whole job. So as is we can't really track what's happening separately. What happens if one fails but one doesn't? etc.

3. There are no cross job compatibility issues if I understand your question correctly. The thinking behind doing separate Flippers is we could implement, test and canary roll out each of these separately instead of testing them all at once. If it was as simple as adding one service with the same call we probably wouldn't have to test each job end to end but we should anyway. However, given they are all a little funky and different it made the most sense to treat each separately