Determine whether an AAMVA check is required in the progressive proofer

[jmhooper]

Prior to this commit we have been passing should_proof_state_id from the VerifyInfoConcern down to the ProgressiveProofer through the async proofing tooling. This requires this argument to be passed down the call stack and stored as a background job argument.

The should_proof_state_id value is determined by configuration that is available to the IdP and the workers. It is not clear why it needs to be computed in the VerifyInfoConcern and passed down through the job to the ProgressiveProofer. This commit shortcuts everything by moving the logic closer to where the value is actually inspected.

[jmhooper]

I am opening this as a draft PR because I expect this change to be incredibly problematic for many unit tests.

[zachmargolis]

needs a rubocop:disable unused right?

[zachmargolis]

worth dropping a comment that this is intended to be removed?

[jmhooper]

Yeah. I'm also going to have to break this pull request into multiple changes since I need to make the changes in the jobs first before making any changes to the args we pass to them.

[zachmargolis]

WDYT of some stronger assertions here? Technically it's new behavior but it might be nice to know if any bad data slips through loudly + early

Suggested change

	state_id_jurisdiction = applicant_pii['state_id_jurisdiction']
	IdentityConfig.store.aamva_supported_jurisdictions.include?(state_id_jurisdiction)
	state_id_jurisdiction = applicant_pii.fetch('state_id_jurisdiction')
	raise "blank state_id_jurisdiction" if state_id_jurisdiction.blank?
	IdentityConfig.store.aamva_supported_jurisdictions.include?(state_id_jurisdiction)

[jmhooper]

Yeah, this is a bit of a change. Let me do it; based on what I've seen in the tests I'll bet a bunch of unit tests will start failing and need to be tidied.

[jmhooper]

I am going to put this back the way it was. It looks like there is some behavior that depends on this fully functioning when PII is missing:

identity-idp/spec/services/proofing/resolution/progressive_proofer_spec.rb

Lines 171 to 185 in ec59a21

	context 'pii is missing' do
	let(:applicant_pii) { {} }
	it 'does not make a request to the ThreatMetrix proofer' do
	expect(threatmetrix_proofer).not_to have_received(:proof)
	end
	it 'returns a failed result' do
	device_profiling_result = proof.device_profiling_result
	expect(device_profiling_result.success).to be(false)
	expect(device_profiling_result.client).to eq('tmx_pii_missing')
	expect(device_profiling_result.review_status).to eq('reject')
	end
	end

I am planning on coming through here and modifying the arguments to match the PII structs we added a while back. I'm hoping to come up with a better solution for handling malformed PII at that point.

[zachmargolis]

thanks for trying!

[aduth]

Are we intending to remove this at some point?