LG-8985 Make "Pass" the default option for mock device profiling result

[jmhooper]

The mock device profiler simulates a tool that assesses device risk. This is specifically meant to simulate the way ThreatMetrix works in deployed environments in local development and sandbox environments.

In deployed environments javascript is added to the page to assess device risk. This javascript phones home to ThreatMetrix. When the user is submitting their information we make a request on the backend to ThreatMetrix for the result.

The ThreatMetrix javascript may be blocked by the client. In this case the backed result will contain a warning code with the value smmry_unkwx_session. The review_status field, which is ultimately what is used to determine whether the user is allowed to proof without further review, will have a value of pass, review, or reject depending on the configuration for this case.

We simulate this behavior by loading javascript that displays a dropdown that allows the user to select the result that will come from assessing their device. This value is saved and returned on a mocked backend request. To simulate the behavior when the Javascript is blocked we have a No Result option which results in the mocked result being null.

At one point we assumed that when a user's client blocks the javascript the result from ThreatMetrix would be null. This, however, is not the case. ThreatMetrix can still make a determination about the session if the Javascript is blocked. Receiving a value of null from Threatmetrix is an invalid state and should be considered an error state.

The "No Result" case, which should be an error state, is the default state in local dev and test environments. This means that people going through proofing fail by default for unclear reasons. This commit makes the default Pass so this no longer happens.

[zachmargolis]

LGTM, do we also want to make that the ruby default for the when there is no key in redis?

[matthinz]

Yeah, I agree this is a better default. Is it possible to end up with a nil Threatmetrix result on the proofing component if the Session Query API call times out or fails in some way (e.g. 5xx)?

[jmhooper]

LGTM, do we also want to make that the ruby default for the when there is no key in redis?

Right now we have 2 different ways of handling nil results. The review controller considers it a fail and the GPO controller considers it a pass. How we should handle them is kind of an open question. I'm going to through together a ticket to propose that a nil result be considered a pass. I think that is out of scope of this PR.

Yeah, I agree this is a better default. Is it possible to end up with a nil Threatmetrix result on the proofing component if the Session Query API call times out or fails in some way (e.g. 5xx)?

That is an interesting question. For the 500 case it does look like we return a nil result. We do that in a few other cases. That is something I'll propose tightening up in the story I mentioned in my response to Zach's question above.