[ELI-619] - cache campaign configs unless we send a reserved consumer id

[TOEL2]

Description

I've implemented an idea that looks like it would be a nice easy fit to grab some performance back.

Added some unit tests to show the cache being used and then expiring

Difficult to fully integration test without deploying but I've showed that it works at least (with a little fudging). This involves setting the env variable to "dev" in the docker set up for local runs, just for that commented out int test.

Context

stops fetching from s3 every single request

Type of changes

• Refactoring (non-breaking change)
• New feature (non-breaking change which adds functionality)
• Breaking change (fix or feature that would change existing functionality)
• Bug fix (non-breaking change which fixes an issue)

Checklist

• I am familiar with the contributing guidelines
• I have followed the code style of the project
• I have added tests to cover my changes
• I have updated the documentation accordingly
• This PR is a result of pair or mob programming

---

Sensitive Information Declaration

To ensure the utmost confidentiality and protect your and others privacy, we kindly ask you to NOT including PII (Personal Identifiable Information) / PID (Personal Identifiable Data) or any other sensitive data in this PR (Pull Request) and the codebase changes. We will remove any PR that do contain any sensitive information. We really appreciate your cooperation in this matter.

• I confirm that neither PII/PID nor sensitive data are included in this PR and the codebase changes.

[TOEL2]

This is just a poc, will wait to add test coverage to see if people like it

[ayeshalshukri1-nhs]

I check the updated PR, looks good. Nice solution.

(previous solution used headers for cache enable/disable)

I think, we might was a bit of thought around how we control the test consumer ids.
Right now, you have a hard coded list. which works fine.
Obviously we would need a release to update, but I dont imagine this to change to often to be honest.

When you originally mentioned this idea, before I looked at the PR,
I thought you where going to modify the actual consumer mapping file, with a flag on the consumer which would say cache enabled or not.

Maybe just needs a bit of thought around this hard coded test consumer ids, see if that is what we want. If yes, then all look great to me, nice solution.