EDM-567/cache lcpe

[jefftmarks]

Summary

• *This work is behind a feature toggle (flipper): NO
• (Summarize the changes that have been made to the platform): EDM frontend team is integrating license, certs, prep course, and exams (LCPE) into the GI Comparison tool. Vets-api facilitates the request upstream to GIDS. Previously existed as a simple pass through service fronted by GIDS Redis facade. LCPE will implement a different pattern with http caching (If-None-Match and Etag headers) to handle relatively large license and certs file.
• (If bug, how to reproduce)
• (What is the solution, why is this the solution?) GIDS will implement versioning with preloaded datasets and verify that the client has the most recent version of data. Vets-api's job is to compare client versions with the currently cached redis version, and then verify that most recent version with GIDS. Vets-api will cache after making a request to GIDS if there's a new version returned (as opposed to existing pattern for other GIDS endpoints which check the cache first before sending requests upstream to GIDS). Diagrams here
• (Which team do you work for, does your team own the maintenance of this component?) Education Data Migration (EDM) yes except for raise_custom_error.rb, which needed to be modified to allow 304s to be returned to client
• (If introducing a flipper, what is the success criteria being targeted?)

Related issue(s)

• https://jira.devops.va.gov/browse/EDM-653
• Edm 653/lcpe cache logic gibct-data-service#1314

Testing done

• New code is covered by unit tests Fixed failing tests. PR already large, so will add new tests in separate PR to cover new files created
• Describe what the old behavior was prior to the change
• Describe the steps required to verify your changes are working as expected. Exclusively stating 'Specs run' is NOT acceptable as appropriate testing Run GIDS and vets-api locally and test http caching using browser
• If this work is behind a flipper:
  • Tests need to be written for both the flipper on and flipper off scenarios. Docs.
  • What is the testing plan for rolling out the feature?

Screenshots

Note: Optional

What areas of the site does it impact?

(Describe what parts of the site are impacted andifcode touched other areas)
GI Bill Comparison tool (once new LCPE integration is launched)

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

Had to add new option into raise_custom_error.rb middleware. Otherwise 304 responses were getting caught and transformed into backend errors and we need them to make it back to client. Is this allowed/preferred solution? Other option would be to duplicate raise_custom_error middleaware and rename it but that seemed repetitive if most of the logic is the same otherwise.