fix(query): make config validation for query controller less strict

[danxmoran]

Related to #21321

In 2.0.4:

• query-concurrency: 0 was not allowed
• The default values of query-concurrency and query-queue-size were both 10

In practice, we found that users quickly hit the default threshold. See #17912.

In 2.0.5:

• query-concurrency: 0 was enabled as a short-hand for infinite concurrency
• Validation was added to assert that:
  • query-queue-size is 0 when query-concurrency is 0
  • query-queue-size is > 0 when query-concurrency is > 0
• The default values of query-concurrency and query-queue-size were both updated to be 0

This is guaranteed to be a breaking change for any users that had updated their deployments to override the config value for query-concurrency without also updating query-queue-size, because concurrency must have been > 0 and queue-size would now be 0 by default.

This PR:

• Changes the default values for query-concurrency and query-queue-size to 1024
• Loosens our config validation to allow query-queue-size > 0 when query-concurrency is 0

The new non-zero defaults should prevent the guaranteed breaking change from 2.0.5, but still give more breathing room to users that have been fighting the concurrency limits in older versions. The validation change should make it smoother for users who want to make use of the new infinite-concurrency feature.

[davidby-influx]

LGTM

Any desire for a maximum Queue size?

[danxmoran]

Any desire for a maximum Queue size?

None that I've seen 🙂 most users (understandably) seem to wish it was unlimited, but that doesn't work with our use of a chan for the queue. I experimented with setting maxint as the queue size and was surprised to learn that make(chan, N) allocates enough space for the buffer of N up-front, so server startup either takes forever or OOMs when the number is "too big".

[davidby-influx]

Ah, lower values only for testing, not for user defaults.