Fix and document discovery queries behavior on distributed queries and add tests

[lucasmrod]

This PR fixes and attempts to document the discovery queries behavior in distributed queries.

The main change:
If a distributed query does not have its corresponding discovery query, then it will always be executed.
(Currently on master this is not the case, if there's at least one discovery query then all those distributed queries that do not have one defined are not executed at all.)

This PR also fixes #5260 and #7793 and adds some tests to Distributed.acceptWork.

[linux-foundation-easycla]

The committers listed above are authorized under a signed CLA.

• ✅ login: lucasmrod / name: Lucas Manuel Rodriguez (89a06da)

[directionless]

I'm not sure I understand how this fixes the bug described in #5260. How is this behavior different that prior? (I'm not enough of a c person to discern if there's something clever happening)

Are there cases hasDiscoveryQueries is false, but not !queries_to_run.empty()?

[lucasmrod]

Hi!, it's a pretty confusing feature/logic.

Currently in master:

1. queries_to_run starts empty.
2. First for loop iterates the received discovery queries. For each discovery query, if they return > 0 results, then the query name is added to queries_to_run.
3. Second for loop iterates the received queries and, "stores them in the database to be run in runQueries" if queries_to_run is empty or if the corresponding discovery query returned > 0 results.

Are there cases hasDiscoveryQueries is false, but not !queries_to_run.empty()?

The bug in master is that if there are discovery queries and all of them return no results, then queries_to_run will be empty, and therefore all queries are incorrectly enqueued for execution (because it's using queries_to_run.empty() in the if).

if (!hasDiscoveryQueries || queries_to_run.count(name)) {

I believe this change fixes the above bug:

• All queries are queued if there are no discovery queries (hasDiscoveryQueries=false).
• If hasDiscoveryQueries=true, then the query is only enqueued if it returned results queries_to_run.count(name) == true.

Let me know if it makes sense.

[lucasmrod]

Also, this PR just fixes a corner-case in the current logic, it does not try to change such logic (discussed in #5260 (comment)).

[lucasmrod]

I've ended up fixing the "odd behavior" and adding documentation instead. Let me know if (by reading docs and tests) it now makes more sense.

[zwass]

This looks to be well-documented and tested. Thank you @lucasmrod! @directionless any further questions/concerns from you? Otherwise I'll merge later today.