Manually add or override addresses announced to Discovery Server

Background: We use Syncthing (extremely satisfied, btw!) in a small team of staff members within the organisation's local network & VPN. Each staff member runs one instance on their laptop, and two instances run on our servers (one on-premise, one cloud/VPS).

To have all instances mutually discover each over smoothly and yet to keep everything within our network/VPN, we also started running a discovery server a while ago. Since then, everything works very smoothly and reliably.

Now I just migrated one of the server instances into a Docker container and face one issue: that Syncthing instance only announces its internal container IP (when NAT disabled), plus the VPS' external/public IP (when NAT enabled). Both aren't the IPs under which other instances can reach it (this would be one of the VPS internal IPs). And it's of course clear that Syncthing couldn't possibly know/find out the other IP.

Feature needed/suggested: It would be a useful feature if one could manually specify IP addresses that the Syncthing instance announces to the Discovery Server (in addition or instead of the local interface IPs).

I guess this could be useful for others running Syncthing in a dockerized setup. Or in any other setup where the instance is actually reachable on a fixed/known IP address that is, however, not one of it's own/visible interfaces.

Workaround used for now: I added the internally-reachable IP as listen address together with wildcard listen addresses. This seems to make Syncthing announce it to the Discovery Server regardless of the fact it can't bind the address.

The downsides are that this does not look very elegant, might not actually be the desired/expected behaviour and pollutes the log with periodic failure messages (rightly so, about not being able to bind those IPs).

Other alternatives considered:

• Running the Syncthing container with host networking mode: doesn't really seem more elegant to me. This would be the only service running in host networking mode.
• Using a local Relay Server: I did not pursue this too far, but it seems overkill somehow and I am not sure again if that would be any more elegant.
• Running a local STUN server: seems overkill, too.

The issue names no files or tests; begin by tracing how Syncthing derives and announces addresses to the Discovery Server from its listen-address and NAT settings. Compare the requested manual addresses with the current workaround, and verify that add and override behavior work without requiring an unbindable address.