Use NastyCache for MeritOrder and Molecules to reduce cache round-trips

[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; with Solid Cache every cache operation is a SQL query.

Implemented changes

MeritOrder and Molecules previously used Rails.cache.fetch on every access. Since this data is purely derived from ETSource and never changes between imports, it is a better fit for NastyCache, which stores values in process memory and avoids a cache round-trip on every access.

NastyCache already handles invalidation correctly across all Puma workers: on ETSource import, expire_local! clears @cache_store on the importing process and mark_expired! writes a new timestamp to Rails.cache. Every other process detects the timestamp change on its next request via initialize_request and clears its own store.

Related

Closes #1747

Checklist

• I have tested these changes
• 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!

[aaccensi]

@noracato , @louispt1 I realized the direction I was taking to improve the caching on these 2 classes was in essence almost using NastyCache, which we already have and it is in fact a minimal change; hence the pivot of this PR.