Fix call to inefficient delete_matched cache method in domain blocks

[ClearlyClaire]

All cached relationships for an account were being cleared in bulk using Rails.cache.delete_matched when blocking an account. However, delete_matched iters through all cache keys and does not have any optimization for matching by prefix, which has a very significant performance impact.

The information of whether an account is domain-blocked by the current user has been moved outside of the relationships cache and is instead cached in a per-domain cache. In the worst case, this would double the number of cache keys used for a relationship cache, but it should slightly reduce the amount of data duplication throughout the cache.

The code has also been changed to use read_multi to request most cache keys at once and thus reduce the number of Redis queries per access to relationship caches. This also changes the relationship cache keys from relationship:<account>:<second_account> to relationship/<account>/<second_account> as it is how Rails internally splits cache key components.

[codecov]

Codecov Report

Attention: 3 lines in your changes are missing coverage. Please review.

Comparison is base (db897ea) 83.49% compared to head (4edf80e) 83.70%.
Report is 20 commits behind head on main.

Files	Patch %	Lines
app/presenters/account_relationships_presenter.rb	89.28%	3 Missing ⚠️

Additional details and impacted files

@@            Coverage Diff             @@
##             main   #28374      +/-   ##
==========================================
+ Coverage   83.49%   83.70%   +0.21%     
==========================================
  Files        1038     1038              
  Lines       28241    28281      +40     
  Branches     4556     4576      +20     
==========================================
+ Hits        23580    23673      +93     
+ Misses       3533     3479      -54     
- Partials     1128     1129       +1     

☔ View full report in Codecov by Sentry.
📢 Have feedback on the report? Share it here.

[mjankowski]

Looks good overall, left some misc style comments ... is there any spec coverage we could around the "reduce redis round trips" portion of this? ... set up some scenario which would have been 2 or 3 round trips before but is now one in the read_multi scenario?

[renchap]

Looks good to me, but I do not know this area very well.

Are there tests covering this?

[ClearlyClaire]

There are tests covering the functionality, but not the performance.

[ClearlyClaire]

The tests are actually only testing the cold cache path, and my understanding of read_multi was incorrect. This needs more work.

[renchap]

Looks good, but if this caused problems after deploying the previous version, then we are probably missing a test?

[ClearlyClaire]

Looks good, but if this caused problems after deploying the previous version, then we are probably missing a test?

Yeah. Just pushed some changes to the specs to add tests for a warm cache.