Endpoint - allowing override server configuration

[BiagioFesta]

The idea here is to reload the server configuration allowing a new setup for incoming connections without dropping the endpoint and closing existing ones.

The main rationale is the fact that, in some circumstances, on long server sessions, it is needed to reload its TLS configuration. In particular, to have the possibility to renew an expiring TLS certificate keeping the server/service operative.

---

Pseudo Code Usage Idea

let (endpoint, mut incoming) = endpoint.bind(&listen_addr).unwrap();

loop {
  select! {
      Some(incoming) = incoming.next() => {
          // Handle new incoming connection
       }
       new_config = config_reload.next() => {
           let new_server_config = build_new_server_config(&config);
           endpoint.override_server_config(new_server_config);
        }
    }
}

[Ralith]

Thanks for the PR! This will be great to have; I honestly didn't realize how easy it would be.

[Ralith]

Thanks!

[Matthias247]

You should already be able to do this with the current config, since the cert is not necessarily static but a lookup callback. Same applies for other functions for which "providers" can be hooked in (like the CidGenerator).

I guess it won't hurt to swap the complete config instead of just adding more callbacks. But the question is whether swapping this config dynamically might break anything that doesn't expect the values to change over time.

[Ralith]

You should already be able to do this with the current config

Good point. Setters are a lot more convenient than setting up a sidechannel, though, and it might be useful to adjust some of the other options on the fly non-disruptively as well.

But the question is whether swapping this config dynamically might break anything

I've audited this and I'm satisfied that there aren't any issues with the current set of config options. We actually don't read the server config in very many places; the overwhelming bulk is in Endpoint::handle_first_packet. At worst, swapping out token_key might cause spurious failure for in-flight handshakes, but that's trivially recoverable and far less disruptive than restarting the endpoint outright. It's also nice for rotating token_key to be enabled in its own right.

What could break things would be changing the config for an existing connection, but existing connections hold onto the Arc of the config they were created with, so that's not a risk.

[Matthias247]

Why allow Option? For servers, this must always be Some.

[Ralith]

Reviewing the code, it looks to me like this will allow enabling/disabling server operation at will, which seems somewhere between harmless and useful, and less surprising than silently doing nothing. I guess we could omit the Option and let it be possible to enable server mode but not disable it, but why not be symmetrical?