QueryHash bug: different queries can share the same hash

[xuorig]

Hey folks, just hit this issue in production. Two queries with different fields/arguments can potentially share a hash, meaning they can share a query plan.

• First commit offers a repro
• Second commit with a fix, but haven't thought through the implications.

[router-perf]

CI performance tests

• step - Basic stress test that steps up the number of users over time
• events_big_cap_high_rate_callback - Stress test for events with a lot of users, deduplication enabled and high rate event with a big queue capacity using callback mode
• large-request - Stress test with a 1 MB request payload
• events - Stress test for events with a lot of users and deduplication ENABLED
• xxlarge-request - Stress test with 100 MB request payload
• events_without_dedup - Stress test for events with a lot of users and deduplication DISABLED
• xlarge-request - Stress test with 10 MB request payload
• step-jemalloc-tuning - Clone of the basic stress test for jemalloc tuning
• events_callback - Stress test for events with a lot of users and deduplication ENABLED in callback mode
• no-graphos - Basic stress test, no GraphOS.
• reload - Reload test over a long period of time at a constant rate of users
• events_big_cap_high_rate - Stress test for events with a lot of users, deduplication enabled and high rate event with a big queue capacity
• events_without_dedup_callback - Stress test for events with a lot of users and deduplication DISABLED using callback mode
• const - Basic stress test that runs with a constant number of users

[abernix]

Ok, @o0Ignition0o, @IvanGoncharov and some other folks are taking a deeper look at this in #5028. I understand that the approach will be to completely back out some of the more nuanced hashing until an approach can be re-applied with a deeper consideration for the side-effects you've seen here.

[xuorig]

Sounds good, yep that works!