Allow assertions on specific cache IDs in performance tests

Coming here from 📌 Convert KernelDestructionSubscriber to use configurators Active where I have perhaps broken something as there are now only 53 cache sets instead of 59.

Wondering if instead of just asserting the number of cache gets/sets, we should actually log and assert the specific keys, as that would help indicate both where things get broken and also where we could aim to look for improvements.

Discovered locally while prototyping #2 that one of the differences is that cache_bootstrap's path_alias_whitelist is not always requested from cache, only sometimes.

That'll be possible after 📌 Separate cache operations from database queries in OpenTelemetry and assertions Fixed which is on my list to do fairly soon.

Opened a draft MR which asserts cache gets in a single test for now, feedback welcome.

@longwave I think that is what assertEqualsCanonicalizing is for? https://docs.phpunit.de/en/9.6/assertions.html#assertequalscanonicalizing

That might help but also the cache keys change a bit for various reasons (so I implemented wildcards) and also we perhaps want to assert ordering in *some* cases, which makes it a bit trickier.

I made a start on 📌 Separate cache operations from database queries in OpenTelemetry and assertions Fixed which means we can get the cids from cache decorators instead of database query parsing once that's in.

Cache gets in different orders is tricky, and will only get worse once we're using fibers more.

The initial purpose of this issue appears to be fixed by 📌 Separate cache operations from database queries in OpenTelemetry and assertions Fixed . The main thing is that when using database queries as a proxy for cache operations, chained fast results in inconsistent numbers, because sometimes things come from apcu and sometimes from the database. I'm now seeing consistent cache operations and database queries over there.

However I think @longwave's idea here is good, so let's repurpose this.