fix: batched queries with same args in diff order

[Weakky]

Overview

fixes prisma/prisma#16267

Query arguments were stored as a list of tuple, preventing queries with the same arguments in different order to be compared properly.

For instance, those two queries:

findUnique(where: { id: 1, name: "Bob" })
findUnique(where: { name: "Bob", id: 1 })

Were transformed to the following list of args:

[
  [("id", 1), ("name", "Bob")],
  [("name", "Bob"), ("id", 1)]
]

When building the map of arguments to results from the result of the findMany query though, this is what we used to construct (note: findMany would return a single result since we're batching the same query twice, so there's, expectedly, a single element in that list):

[
  ([("id", 1), ("name", "Bob")], <query result>)
]

Unfortunately, [("id", 1), ("name", "Bob")] is not equal to [("name", "Bob"), ("id", 1)], so we'd never find the result for the second query, resulting in a null (or vice-versa, depending on the order of the selection set of the findMany query).

This PR fixes this issue by storing the query arguments as HashMaps so that they can be compared regardless of order: { id: 1, name: "Bob" } == { name: "Bob", id: 1 }.

Note that the PartialEq impl. for HashMap is not magic and requires iterating over all (k,v) of one of the hashmaps:

#[stable(feature = "rust1", since = "1.0.0")]
impl<K, V, S> PartialEq for HashMap<K, V, S>
where
    K: Eq + Hash,
    V: PartialEq,
    S: BuildHasher,
{
    fn eq(&self, other: &HashMap<K, V, S>) -> bool {
        if self.len() != other.len() {
            return false;
        }

        self.iter().all(|(key, value)| other.get(key).map_or(false, |v| *value == *v))
    }
}

It still remains far more efficient than doing the comparison with two Vecs.

[miguelff]

Neat fix. 👏🏾

[miguelff]

This is very much appreciated and explains a bit the reason behind prisma/prisma#16267