Refactor mullvad-relay-selector

[MarkusPettersson98]

Buckle up!

This PR builds on the foundations laid out in #5835 by implementing a system for choosing appropriate relay(s) built on 'queries'. The intent is to make working with the relay selector as declarative as possible while simplifying and modularizing its internals.

Elevator pitch

Tell the computer what you want, not what to do - ElKowar

A query is a set of constraints which dictates which relay(s) that can be chosen by the relay selector.

The user's relay constraints (settings) can be expressed as a query. The semantics of merging two queries in a way that always respects user settings is defined by the new Intersection trait. It should be easy to correlate the code found in the new mullvad-relay-selector crate with the description found in the relay selector document on how it should behave.

Code changes

Retrofitting this new system for driving the relay selector through queries was not possible without rewriting most of mullvad-relay-selector. Here is a short breakdown of the new crate structure

• src/lib.rs: The public API of the mullvad-relay-selector crate.
• src/relay-selector/mod.rs: The new module where RelaySelector is defined. This is still the largest module in the crate (except for tests).
• src/relay-selector/query.rs: Definition of a query on different types of relays. This module is integral to the new API of mullvad-relay-selector
• src/relay-selector/matcher.rs: Logic for filtering out candidate relays based on a query.
• src/relay-selector/detailer.rs: Logic for deriving connection details for the selected relay(s). This could arguably live outside of the mullvad-relay-selector crate. For now, I placed it here since this logic was in the old mullvad-relay-selector.
• tests/: Integration tests for the new relay selector. These tests only use the public APIs of RelaySelector and make sure that the actual output matches the expected output in different scenarios. This is the spiritual successor to the tests found in the old mullvad-relay-selector crate.
• The rest of the modules found in the new mullvad-relay-selector crate is either not that interesting or self-explanatory.

---

This change is 

[linear]

DES-543 Optimize order of connection parameters when trying to connect

[dlon]

Reviewed 8 of 8 files at r36, 6 of 8 files at r37, 3 of 3 files at r38, all commit messages.
Reviewable status: all files reviewed, 29 unresolved discussions (waiting on @MarkusPettersson98 and @Serock3)

---

mullvad-relay-selector/src/relay_selector/mod.rs line 119 at r36 (raw file):

/// The second one is a custom config, where [`SelectorConfig::relay_settings`] is [`RelaySettings::Custom`].
/// For this variant, the endpoint where the client should connect to is already specified inside of the variant,
/// so in practice the relay selector becomes superflous. Also, there exists no mapping to [`RelayQueryBuilder`].

Nit: superfluous

---

mullvad-types/src/relay_constraints.rs line 396 at r38 (raw file):

#[derive(Debug, Clone, Eq, PartialEq, Deserialize, Serialize)]
pub struct Providers {
    pub providers: HashSet<Provider>,

Can we make it not public? I think losing the encapsulation means you technically lose the guarantee of it being non-empty.

---

talpid-types/src/net/mod.rs line 563 at r38 (raw file):

    pub fn has_ipv6(&self) -> bool {
        match self {
            Connectivity::Status { ipv6, .. } => *ipv6,

Nit: matches!(self, Connectivity::Status { ipv6: true, .. })

[MarkusPettersson98]

Reviewable status: all files reviewed, 27 unresolved discussions (waiting on @dlon and @Serock3)

---

mullvad-types/src/relay_constraints.rs line 396 at r38 (raw file):

Previously, dlon (David Lönnhager) wrote…

Can we make it not public? I think losing the encapsulation means you technically lose the guarantee of it being non-empty.

Yes, you are right. Getting a read-only reference to the underlying set of providers is enough for my use case anyway, so I'll go ahead and add a method for that 😊

[dlon]

Reviewed 5 of 5 files at r39, all commit messages.
Reviewable status: all files reviewed, 26 unresolved discussions (waiting on @Serock3)

[dlon]

Reviewed 5 of 5 files at r40, 1 of 1 files at r41, all commit messages.
Reviewable status: all files reviewed, 26 unresolved discussions (waiting on @Serock3)

[dlon]

Reviewed 5 of 5 files at r42, all commit messages.
Reviewable status: all files reviewed, 25 unresolved discussions (waiting on @Serock3)

[dlon]

Reviewed 3 of 3 files at r43, all commit messages.
Reviewable status: all files reviewed, 25 unresolved discussions (waiting on @Serock3)

[raksooo]

Reviewed 1 of 1 files at r44, 1 of 1 files at r45.
Reviewable status: all files reviewed, 25 unresolved discussions (waiting on @Serock3)

[dlon]

Reviewed 3 of 3 files at r46, all commit messages.
Reviewable status: all files reviewed, 25 unresolved discussions (waiting on @Serock3)