Batch etsource cache reads with fetch_multi to reduce N+1 queries

[aaccensi]

Context

Since adopting Solid Cache, several controller actions that trigger a GQL calculation are flagged by Sentry as N+1 queries. This was not visible before because Memcached round-trips are cheap and don't use SQL; with Solid Cache every cache operation is a SQL query. The fix implemented is cache-backend agnostic.

Implemented changes

MeritOrder collapses 6 individual cache fetches into one fetch_multi call. Molecules does the same for its 2 keys. Both use Thread.current to ensure fetch_multi runs at most once per request.

Notice that Fever and Reconciliation were not changed: Fever has a single key so batching adds no value, and Reconciliation has a dependency between its two keys (reconciliation_hash is computed using reconciliation_carriers, so they cannot be fetched in a single fetch_multi)

Related

Closes #1747

Checklist

• I have tested these changes (I believe this cannot be tester properly locally)
• I have updated documentation as needed
• I have tagged the relevant people for review

[louispt1]

I've looked at this a couple of times but I am not confident about it without more investigation.
This cache means that the merit order is preserved for the lifetime of a rails thread, I guess I'm concerned the cache won't be invalidated correctly? But not sure how to test/verify this. I see that this gem notes the issue and provides a solution, but I am not entirely sure we will even face the issue to begin with. I think we may need to test this carefully

I also see as I was typing this you've updated the cache clearance @aaccensi so maybe all moot now - will take a look later on

[aaccensi]

I was looking at the situation with stale data that we should not get after an ETSource import that the solid cache investigation flagged and decided to try to factor also this in here as a test making it more optimal.

[louispt1]

I've looked at this a couple of times but I am not confident about it without more investigation. This cache means that the merit order is preserved for the lifetime of a rails thread, I guess I'm concerned the cache won't be invalidated correctly? But not sure how to test/verify this. I see that this gem notes the issue and provides a solution, but I am not entirely sure we will even face the issue to begin with. I think we may need to test this carefully

I also see as I was typing this you've updated the cache clearance @aaccensi so maybe all moot now - will take a look later on

Discussed with @aaccensi and I understand the approach now - I was a little confused before but the approach makes sense to me now and seems practical!