Corrective Action: Ensure errors from ArkoseLabs API endpoints fail gracefully

Summary

While the error was logged and visible on demand in Kibana, it did not surface in the application as an error and the HTTP status code for these calls was 200 OK. This is because we swallow and log these failures here. This is a problem, because it will not affect Apdex and hence SLO trackers.

Related Incident(s)

Originating issue(s): production#18341 (closed)

Desired Outcome/Acceptance Criteria

• Ensure that the Arkose::TokenVerificationService success response is consistent. Differing success payloads contributed to this incident.
• Ensure the Arkose::TokenVerificationService does not block registration when unexpected errors happen. If the API fails with an error due to either an invalid public key or invalid session token, then the response body will be {"error":"DENIED ACCESS","verified":"2024-08-05T19:33:44Z"}. If the API call fails due to malformed client data in other fields then the response body will be empty. We should not surface errors to the client when the error is not DENIED ACCESS
• Feature specs should be added to ensure we fail gracefully with unexpected arkose errors but block user actions when they are denied access.

Associated Services

Corrective Action Issue Checklist

• Link the incident(s) this corrective action arose from
• Give context for what problem this corrective action is trying to prevent re-occurring
• Assign a severity label (this is the highest sev of related incidents, defaults to 'severity::4')
• Assign a priority (this will default to 'Reliability::P4' but should match the severity of the related incident)
• Assign a service label
• Assign a team label