[Pension Burials] Handle 403 errors

[TaiWilkin]

Are you removing, renaming or moving a folder in this PR?

• No, I'm not changing any folders (skip to TeamSites and delete the rest of this section)
• Yes, I'm removing, renaming or moving a folder

⚠️ TeamSites ⚠️

Examples of a TeamSite: https://va.gov/health and https://benefits.va.gov/benefits/. This scenario is also referred to as the "injected" header and footer. You can reach out in the #sitewide-public-websites Slack channel for questions.

Did you change site-wide styles, platform utilities or other infrastructure?

• No
• Yes, and I used the proxy-rewrite steps to test the injected header scenario

Summary

• In some cases, users can be blocked from submitting their form by an expired or invalid CSRF token. Users can only correct this error by refreshing their page, which can cause them to lose entered data.
• This PR adds handling to attempt to refresh the CSRF token at the beginning of requests if it isn't found. If the CSRF token is found but the request fails due to CSRF token issues, we try to refresh to CSRF token, then retry the request once.

Related issue(s)

• Pensions and Burials 403 Errors va.gov-team#103407

Testing done

Mimic the CSRF error

• In the application local storage, replace csrfToken with one that's expired (I can provide one if needed)

Mimic a non-CSRF error

• throw an error in the Burials/Pensions claims controller

Test various scenarios for Pensions and Burials

• Submission should succeed if CSRF token is not invalid
• Submission should succeed if CSRF token is invalid starting on earlier page of form
• Submission retry should succeed if CSRF token is invalid starting on review page
• Submission should fail with UI message if a non-CSRF error occurs on first attempt
• Submission retry should fail with UI message if a non-CSRF error occurs on retry attempt

What areas of the site does it impact?

Pensions and Burials

Acceptance criteria

Quality Assurance & Testing

• I fixed|updated|added unit tests and integration tests for each feature (if applicable).
• No sensitive information (i.e. PII/credentials/internal URLs/etc.) is captured in logging, hardcoded, or specs
• Linting warnings have been addressed
• Documentation has been updated (link to documentation *if necessary)
• Screenshot of the developed feature is added
• Accessibility testing has been performed

Error Handling

• Browser console contains no warnings or errors.
• Events are being sent to the appropriate logging solution
• Feature/bug has a monitor built into Datadog or Grafana (if applicable)

Authentication

• Did you login to a local build and verify all authenticated routes work as expected with a test user

[mjknight50]

GTG

[TaiWilkin]

@mjknight50 Sorry, can you re-approve? I had to handle a merge conflict

[mjknight50]

GTG