Prevent `HomeserverConfig::discover` from performing the `discover` request if previous server info exists

[jmartinesp]

In the clients we restore the session using the fn ClientBuilder::homeserver_url to restore the previous homeserver URL. However, this modifies the HomeserverConfig the client is built with, so if we had used HomeserverConfig::ServerNameOrHomeserverUrl or HomeserverConfig::ServerName when we logged in we'll now use HomeserverConfig::HomeserverUrl and that will override the existing homeserver config, so when we try to reset the server info we'll try to fetch the server name for that, which is no longer there.

We'd need to use ClientBuilder::server_name_or_homeserver_url instead, or a variant that allows passing both values. But then, this forces a server info fetch operation when we build the Client and if this fails, it won't be built, so no more offline mode in any implementing clients.

So what we really need is some way to allow that request to fail when restoring an existing session, while also making sure we can retrieve the existing server info from the StateStore. Which isn't accessible before the Client is created.

[zecakeh]

The problem is for the .well-known info right? Why not use the server name of the user ID as first fallback before attempting to use the homeserver URL? When restoring a session, the user ID should be restored too and in theory that should be the proper location for the .well-known.

Also the only data from .well-known that is used after logging in is the rtc_foci if I'm not mistaken, and MSC4143 changed the location where this info is found to a new GET /rtc/transports endpoint which is implemented in Synapse, so it seems like updating the MSC implementation would actually fix any issue with that?