Changes aggregation pipelines that are produced for query requests that include variable sets. Previously we used a $facet sub-pipelines where each sub-pipeline was a copy of the query pipeline with different variable values interpolated. Variable values were written directly into the pipelines at use sites.

This PR removes the $facet stage, and instead feeds variable sets into the start of the pipeline using a $documents stage which feeds into a $lookup stage that contains the query pipeline as a sub-pipeline. So we only have one copy of the query pipeline. Instead if interpolating variable values into that pipeline, we use MongoDB variables to reference values from the $documents stage.

This change has two big benefits:

• using $lookup instead of $facet allows the use of indexes
• the new pipeline is valid even with zero variable sets which fixes a bug we had where connector /explain requests would fail if the connector is the target of a remote join

The downside is that in my testing use of a $documents stage fails in MongoDB 5 with this error:

Kind: Command failed: Error code 5491300 (Location5491300): $documents' is not allowed in user requests, labels: {}

We're investigating this issue to see if it can be fixed. For this PR I have skipped integration tests involving variable sets when testing MongoDB 5. (The tests do run in MongoDB versions 6 & 7.)

A couple of considerations came up while making the changes for this PR. The biggest is that since we are now injecting variables in the first stage of the pipeline we need to know types for those variables up front to apply JSON-to-BSON conversions. To handle that I updated the plan_for_query_request state struct to record types for each use of each variable, and i added a variable_types map to the QueryPlan struct. It is possible for one variable to appear in multiple contexts in the query with different types. Previously we did the BSON conversion at each use site, so we would convert to BSON differently at each site as appropriate for the expected type. Moving variable serialization to a central point requires either an attempt at type unification, or setting separate values for each variable for each distinct type context. I opted for the latter. So the variables written into the aggregation pipeline have names with type suffixes to distinguish different possible BSON serializations.

The other consideration was that the pipeline change results in a different response shape. So I also had to touch response serialization. Thankfully the new response serialization came out a little simpler than it used to be.

MDB-113