Fail SearchV2 requested with unreachable queries

[cthulhu-rider]

Is your feature request related to a problem? Please describe.

no object can ever match following queries:

1. N < X && N > X-like
2. N < -MaxUint256, N <= -MaxUint256-POS, N > MaxUint256, N >= MaxUint256+POS
3. ???

1 is 4ever false while 2 is a current protocol limit (false until extensions)

currently, SearchV2 server responds w/ empty result and OK to any mentioned query. From one side, this is correct: no object matches these filters. From the other one, when OK recved, client cannot distinguish "not found for now" from "not found and will never be" states. This can hide some app-side bugs and worsen the understanding of sys behavior

Describe the solution you'd like

respond to unreachable queries with particular status:

• Bad Request to limit overflows
• specific non-zero one to unreachable queries (can also be 400)

Describe alternatives you've considered

keep returning empty OK result

Additional context

• Implement searchv2 #3058
• Extend metabase filter fast-check #1148

[roman-khimov]

I'm somewhat concerned about deliberately slow queries. We're mostly making them to be efficient since we need performance and fast replies, but an attacker can make v2 work about the same time as v1 did returning zero or some small number of results. And this would be cluster-wide. I don't see a lot of ways to solve it other than some timeouts, but those wont't be trivial either (need to be checked while iterating over the DB).

[cthulhu-rider]

sounds like QoS control with limits and a fee for the load. In theory, it sounds interesting, in practice, we aint even close