[81760] Adding special error case to ToU provisioner response when user cannot be provisioned

[bosawt]

Summary

• This PR adds an error case to the Provisioner class for Terms of User Controller that raises an error when the user cannot be provisioned

Related issue(s)

• change update_provisioning error response when user cannot be provisioned va.gov-team#81760

Testing done

• Forced response from update provisioning to ensure that cerner_provisioning was false in response, and then ensured that ToU Controller update_provisioning and accept_and_provision returned an error with the message Account not Provisioned

What areas of the site does it impact?

• Terms of Use, Authentication

Acceptance criteria

• Default update_provisioning mock should have the CernerProvisioned: false field to create this error
• Call terms_of_use_agreements/update_provisioning and terms_of_use_agreements/:version/accept_and_provision
• Confirm error with the message Account not provisioned

[rileyanderson]

Do we want to change the log here? Maybe the intent is to log that the call itself was successful but it is kinda confusing how we log update provisioning success when provisioning fails. these are the logs we get for a failed provisioning:

Rails -- [MAP][SignUp][Service] update provisioning success, icn: 1008596379V859838
Rails -- [TermsOfUse] [Provisioner] update_provisioning error -- { :icn => "1008596379V859838", :response => { :agreement_signed => true, :opt_out => false, :cerner_provisioned => false, :bypass_eligible => true } }
Rails -- [TermsOfUseAgreementsController] update_provisioning error: Account not Provisioned -- { :icn => "1008596379V859838" }```

[rileyanderson]

update_provisioning looks good. I get a 422 when provisioning fails:

accept_and_provision should be good once that error is rescued

[bosawt]

Do we want to change the log here? Maybe the intent is to log that the call itself was successful but it is kinda confusing how we log update provisioning success when provisioning fails. these are the logs we get for a failed provisioning:

Rails -- [MAP][SignUp][Service] update provisioning success, icn: 1008596379V859838
Rails -- [TermsOfUse] [Provisioner] update_provisioning error -- { :icn => "1008596379V859838", :response => { :agreement_signed => true, :opt_out => false, :cerner_provisioned => false, :bypass_eligible => true } }
Rails -- [TermsOfUseAgreementsController] update_provisioning error: Account not Provisioned -- { :icn => "1008596379V859838" }```

I think we still want to say 'success' but maybe give more context, like the json array with tou status, provision status, etc. Cause it is technically a successful call to that endpoint, it's just the response makes us error

[bosawt]

Do we want to change the log here? Maybe the intent is to log that the call itself was successful but it is kinda confusing how we log update provisioning success when provisioning fails. these are the logs we get for a failed provisioning:

Rails -- [MAP][SignUp][Service] update provisioning success, icn: 1008596379V859838
Rails -- [TermsOfUse] [Provisioner] update_provisioning error -- { :icn => "1008596379V859838", :response => { :agreement_signed => true, :opt_out => false, :cerner_provisioned => false, :bypass_eligible => true } }
Rails -- [TermsOfUseAgreementsController] update_provisioning error: Account not Provisioned -- { :icn => "1008596379V859838" }```

I updated the log to still say update provisioning success, but now it returns the update provisioning response so should be easier to see what's going on there

[rileyanderson]

Looks good