Adding controller / route for EVSS benefits claims

[jerekshoe]

Summary

Adding a separate controller for EVSS claims that does not include any serialization. The new routes are not intended to be consumed by vets-website and their only purpose is for debugging. I have been collaborating with Lighthouse on the new version of their Benefits Claims API which is intended to replace the EVSS claims API in vets-api and we have run into a lot of issues with the API not being consistent with the EVSS version. This controller should make it easier to see what EVSS is returning before any modifications have been made in vets-api via serializers. Since this isn't intended to be used for purposes outside of debugging, I don't intend to include any specs at this time. This controller will go away when the EVSS to Lighthouse migration effort has completed

• (Summarize the changes that have been made to the platform)
• (If bug, how to reproduce)
• (What is the solution, why is this the solution)
• (Which team do you work for, does your team own the maintainence of this component?)
• (If using a flipper, what is the end date of the flipper being required/success criteria being targeted)

Related issue(s)

• [CST] Add new controller for EVSS Claims Raw Response va.gov-team#56919
• Link to ticket created in va.gov-team repo
• Link to previous change of the code/bug (if applicable)
• Link to epic if not included in ticket

Testing done

• Describe what the old behavior was prior to the change
• Describe the steps required to verify your changes are working as expected
• Describe the tests completed and the results

Screenshots

Note: Optional

What areas of the site does it impact?

(Describe what parts of the site are impacted andifcode touched other areas)

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 or Grafana (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?

[ryan-mcneil]

👌

[jerekshoe]

I wasn't planning on creating specs for this because I don't intend for it to be consumed by any services. I just wanted to get this out quickly to help deal with debugging some issues with another API and I'm having issues with the argoCD terminal because the JSON for these is often quite large and there is a limit for how how many lines are kept in the history