Log every individual query in performance tests

So the MR is a proof of concept.

1. The goal is to allow us to track queries that are highly variable and we don't really care about with aliases: watchdog_insert, sessions_insert, sessions_select, etc. We still see what happened, but without the detail.
2. Then, we replace highly variable arguments such as timestamp, IP address, username, etc. with capitalized keywords, such as TIMESTAMP, CLIENT_IP, etc.

This allows us to build a list of expected queries and compare it to what was actually tracked. We may need to sort the queries before comparing, but so far on my local they have always been in the same order.

NW because this isn't finished yet.

Seeing a lot of SELECT "tag", "invalidations" FROM "cachetags" WHERE "tag" IN . We could perhaps track those separately like we do with cache gets, sets, etc. by checking for the calling class being DatabaseCacheTagsChecksum.

Just like we already check for DatabaseBackend to only log queries that didn't come from the DB cache, we could add in DatabaseCacheTagsChecksum to not track those queries either, then decorate cache_tags.invalidator.checksum and add some tracking in there.

Oops, cross-posted.

Okay so the final fail I'm seeing is related to a block ID being random (e.g.: "config:block.block.jf547b5k"8). But that only happens in a cache tag invalidation and as I wrote above we can stop tracking those as queries and simply do a count on them without being too specific.

So StandardPerformanceTest looking really good now. Need to apply the same approach to the Umami performance tests. But I'm on vacation as of right now, so will have to wait until next week :)

In the process of setting up a new laptop but once I'm settled in I'll review the other issue and merge it into this one

Will merge in the changes from #3421881: Track cache tag queries separately in performance tests and tag this issue as PP-1 if the other hasn't been committed by then.

Merged in your work, will see what testbot thinks.

Tests go green with exact query counts, will try and do the same for Umami tests tomorrow.

All performance tests go green with exact query counts on my local now. I also removed the query aliasing in favor of parameter aliasing.

However, on one occasion, StandardPerformanceTest::testLoginBlock() had one extra query as the second-to-last query:

This was expected
      'SELECT "session" FROM "sessions" WHERE "sid" = "SESSION_ID" LIMIT 0, 1',
      'SELECT "name", "value" FROM "key_value" WHERE "name" IN ( "system.cron_last" ) AND "collection" = "state"',

This actually happened
      'SELECT "session" FROM "sessions" WHERE "sid" = "SESSION_ID" LIMIT 0, 1',
      'DELETE FROM "sessions"  WHERE "timestamp" < "TIMESTAMP"',
      'SELECT "name", "value" FROM "key_value" WHERE "name" IN ( "system.cron_last" ) AND "collection" = "state"',

Grafana reported this as coming from Drupal\Core\Session\SessionHandler, so this may be related to #3033791: Do explicit session garbage collection on cron

Other issue got committed, so dropping the PP tag and removing draft status from the MR.

Made the two methods static