LG-6399 Update react app to use new API requests

[nprimak]

LG-6399

Why
Finishing up the api work that @peggles2 started with this PR . Hooking up api to react app for async document capture.

[aduth]

TIL that we had previously been creating a distinct DocumentCaptureSession record for the document capture async verification:

identity-idp/app/services/idv/actions/verify_document_action.rb

Line 38 in ec17ed1

create_document_capture_session(verify_document_capture_session_uuid_key)

This is not the same record as the one we populate into the document capture page and attach to all its API requests, which is the one created at the first welcome step:

identity-idp/app/services/idv/steps/welcome_step.rb

Line 8 in ec17ed1

create_document_capture_session(document_capture_session_uuid_key)

identity-idp/app/views/idv/shared/_document_capture.html.erb

Line 21 in ec17ed1

document_capture_session_uuid: flow_session[:document_capture_session_uuid],

identity-idp/app/javascript/packs/document-capture.jsx

Lines 105 to 108 in ec17ed1

	const formData = {
	document_capture_session_uuid: appRoot.getAttribute('data-document-capture-session-uuid'),
	locale: document.documentElement.lang,
	};

I'm assuming this was intentional, though I'm not really familiar with the reasoning. And if we do want to continue doing creating distinct records, I've a few thoughts:

1. Was it not an issue / inconsistency that the hybrid mobile would be using the welcome step session?
2. Maybe we should create the distinct record when the document capture step is visited, so that we can initialize the view with that one instead of the one created at the welcome step?

cc @zachmargolis @stevegsa for thoughts / insights (via git blame'd #4313, #4665)

[zachmargolis]

I think the idea was we'd create a separate DocumentCaptureSession recod for each step, since each one would have a separate result_id and we'd minimize the risk of overriding one step with another... I have no memory of how it affects the hybrid flow....

If I was starting from scratch, maybe I'd have one table with like a separate column for resolution_result_uuid, address_result_uuid and document_result_uuid or something but 🤷

[aduth]

@zachmargolis Thanks. Curious, though: In that framing, what's the purpose of the session created during the welcome step?

I'm starting to dig into restoring the behavior of a distinct "verify document" session, but the more I implement of it, the more it feels we can / should just repurpose the initial session for this, since (a) the welcome session wouldn't otherwise have a "result" that I'm aware of, and (b) to support hybrid, I expect we would need to create the verify result session fairly early anyways (I was looking at "agreement" step) so that it can be referenced in both document_capture and link_sent flows.

[zachmargolis]

I'm reaching the limits of my memory and my ability to unpack what this was supposed to do....I think the one created at the welcome step was probably meant to be shared across desktop + mobile in the hybrid flow

[aduth]

Yeah, it seems that it's used today for hybrid flow. I guess what I'm proposing is to use that everywhere in place of the distinct "verify document action" session which was used for desktop. That's essentially what this pull request is doing in its current form.

[solipet]

LGTM. Was there resolution on the DocumentCaptureSession ?