[WIP] feat: Basic multi-relay onboarding

[Hocuri]

• We need a list of chatmail relays that we somehow trust, and that agree to be in the list. Then, we add all of them to the candidate list (a new SQL table with colums "domain" and "last_tried").
• Before going to IMAP IDLE: When there are less than 3 relays, fill it up with relays from the candidate list. If creating an account fails, try again with another relay from the list. For each candidate, we need to remember the last time we tried to add a transport there, and try at most once a week or so per candidate.
  • For now, this will be behind an off-by-default config option, which at least DC Android will enable when creating a new profile. UIs can then opt in on their own pace but will likely need to disable it for tests. If the user manually deletes a relay, we should also disable this config option.
  • Open questions: What are the backoff times? Try to add a relay at most once per hour, and try to add the same relay at most once per week?

[Hocuri]

This is working nicely on my Android phone already. Automated tests will be hard. I started writing a python test:

Details

def test_automatic_transport_addition(acfactory, log) -> None:
    alice = acfactory.new_configured_account()
    # This should already add a transport:
    alice.wait_for_event(EventType.TRANSPORTS_MODIFIED)

    alice.set_config("automatic_transport_management")
    alice.bring_online()

    # 2 more transports should be added:
    alice.wait_for_event(EventType.TRANSPORTS_MODIFIED)
    alice.wait_for_event(EventType.TRANSPORTS_MODIFIED)

    transports = alice.list_transports()
    print("transports:", transports)
    # TODO: Sanity-check the list of transports

...then remembered that @link2xt said we shouldn't contact the other relays from the automated tests.

We could just not test it automatically, and do more extensive manual testing, at the risk of more regressions.

We could modify configure() with conditional compilation (#cfg[not(test)]) not to do any network connections when it's called from a Rust test. This will not change the behavior for Python tests. @link2xt you are generally against conditional compilation for tests, because then the tested code isn't the same code as the production code, but right now configure() isn't called from Rust tests at all, so maybe that's fine?

We could extract some functions from maybe_add_additional_transports_inner(), and test them separately, esp. the SELECT domain SQL statement.

@link2xt what do you think?

[Hocuri]

Some more options for writing tests:

• Dependency injection so that the test can disable the part of configure() that does network tests, either via a function parameter or via a trait type parameter. The latter is probably better, because trait parameters can have default values; both of them will be hard for non-rust-experts to read and understand.
• A function parameter skip_network_connections that can be set by the tests
• A simple test that holds the lock / sets Config::LastAutomaticTransportManagement and checks that the function immediately returns (that one probably makes sense no matter what).

I will look at these options again tomorrow, and maybe @link2xt has commented by then.