Feature request: An option to only use `Peers:` as fallback

[Mihara]

Consider the following situation:

I have yggdrasil installed on a laptop which alternates between multiple networks (and ISPs) depending on time of day and situation.

1. In one network, there is a host accessible through peer discovery that has a stable connection to the rest of the network, e.g. yggdrasil running on a router and open for discovery in the LAN.
2. In the other, there is no such host, but there may or may not be peers in the LAN.
3. In yet other cases, the host is connecting over a 4G dongle, so there can be no peers.

In situation 1, I would prefer to have an empty Peers: section, so as not to confuse the routing. In situation 3, I would prefer to have a list of known peers to connect to over the internet. Situation 2 presents some issues, in that if I do have local peers, that doesn't necessarily mean any of them has a connection to the rest of the network, and there's no clean way to know.

But while I don't know how to deal with situation 2, situations 1 and 3 should be easy to account for. A configuration option to behave as if I have no Peers: if there are discovered peers, or otherwise prioritize discovered peers over fixed peers would be enough. Lacking it, I just observed a situation where my machine deep inside a LAN suddenly became an intermediary for an 1 Mb/s connection for no obvious reason.

[Mihara]

In fact, here's my own take on the solution.

[ab2525]

+1 to this. As someone who experiments with a lot of peering and am a yggdrasil evangelist IRL, I end up relaying quite a bit of traffic through my personal machines which is not my own, despite also running it on my routers.

Maybe something like a PeerPreference option, with values auto (current behavior, maybe multicast enablement setting is controlled via this being set to auto?), trusted (a new option that behaves like peerman, "if trusted key found on multicast, use that, otherwise use configured peers")

If #1270 is implemented I could also see a third option here called prefertrusted which implements an artificial latencyshift (aka depreference) to any multicast-discovered peers which aren't on the trusted key list