vi-35 ToU check agreement changed

[emilykim13]

Note: Delete the description statements, complete each step. None are optional, but can be justified as to why they cannot be completed as written. Provide known gaps to testing that may raise the risk of merging to production.

Summary

• Added logic to SignUpServiceJob to process only one Accept/Decline request.
• Added logging for when agreement is not changed.

Testing done

• start vets-website, vets-api, and start sidekiq in vets-api bundle exec sidekiq
• Locally, log in with a user that has not accepted/declined ToU and then accept/decline the ToU. (Although you are changing the agreement, the log for "Agreement not changed" could show up due to your map/sign_up_service/status/default.yml file.)
• Go to map/sign_up_service/status/default.yml to change the agreementSigned and optOut values to what you desire to test.
• Open a rails console bin/rails c.
• Run TermsOfUse::Acceptor.new(user_account: ua, version: 'v1').perform! or TermsOfUse::Decliner.new(user_account: ua, version: 'v1').perform! I set ua to the user_account I am testing. Based on what agreementSigned and optOut is set to in map/sign_up_service/status/default.yml, the log Agreement not changed could show in sidekiq. The accept/decline possibilities are below

Local ToU Accepted, no SuS ToU -> tou_agreement.accepted == true, SuS declined? == false, SuS accepted? == false, call SuS
Local ToU Accepted, SuS ToU Accepted -> tou_agreement.accepted == true, SuS declined? == false, SuS accepted? == true, don't call SuS
Local ToU Accepted, SuS ToU Declined -> tou_agreement.accepted == true, SuS declined? == true, SuS accepted? == false, call SuS
Local ToU Declined, no SuS ToU -> tou_agreement.declined == true, SuS declined? == false, SuS accepted? == false, call SuS
Local ToU Declined, SuS ToU Accepted -> tou_agreement.declined == true, SuS declined? == false, SuS accepted? == true, call SuS
Local ToU Declined, SuS ToU Declined -> tou_agreement.declined == true, SuS declined? == true, SuS accepted? == false, don't call SuS

Acceptance criteria

• I fixed|updated|added unit tests and integration tests for each feature (if applicable).
• No error nor warning in the console.
• Events are being sent to the appropriate logging solution
• Documentation has been updated (link to documentation)
• No sensitive information (i.e. PII/credentials/internal URLs/etc.) is captured in logging, hardcoded, or specs
• Feature/bug has a monitor built into Datadog (if applicable)
• If app impacted requires authentication, did you login to a local build and verify all authenticated routes work as expected
• I added a screenshot of the developed feature

Requested Feedback

(OPTIONAL)What should the reviewers know in addition to the above. Is there anything specific you wish the reviewer to assist with. Do you have any concerns with this PR, why?

[bosawt]

Looking good, overall appears to work as expected, but I have a number of comments to clean up the implementation a bit, and to refactor the specs to kinda more closely match how RSpec should be organized

[rileyanderson]

Just some minor logic and style suggestions. Also, if a user has never accepted nor declined an agreement with map will the status endpoint still return something?

[bosawt]

Just some minor logic and style suggestions. Also, if a user has never accepted nor declined an agreement with map will the status endpoint still return something?

Yes, status will return false for everything. Also, I tested out status with a few values, and as long as it somewhat resembles an ICN it will return some value.:

[rileyanderson]

Looks good