A destination set from the dashboard never reached a connected peer. The peer
fan-out that follows a settings change builds its sync with a nil server config,
and toNetbirdConfig returns nil for that, so no NetbirdConfig went out at all and
the peer kept whatever it had. The new URL only arrived when the peer
reconnected, and until then its bundles kept going to NetBird's upload service —
which is the disclosure this PR exists to close.
PeerConfig is the message the fan-out already fills from the account settings,
alongside the other knobs an operator flips at runtime: lazy connection, MTU,
routing-peer DNS resolution, auto-update. The destination belongs with them.
Sending a partial NetbirdConfig from the fan-out instead would be worse: clients
treat a non-nil one as authoritative for relay and would drop their relay URLs.
Start now reads the destination off the PeerConfig it was given in the previous
commit, for the same reason it used to read it off NetbirdConfig: without it, a
bundle collected between login and the first sync sees no destination, and the
first seconds after a start are exactly when someone collects a bundle about a
start that went wrong.
DebugConfig is removed rather than deprecated. It was added earlier in this
branch and has never been in a release, so no deployed client reads it.
Pure plumbing, no change on the wire. Both halves exist for the same reason: the
value this PR needs to publish is not reachable from the code paths that have to
publish it, and widening the signatures is separable from moving the value.
On the management side, the resolution between the account setting and the
server-config default moves into resolveDebugUploadURL, and the default becomes a
parameter that ToSyncResponse and ToComponentSyncResponse take rather than
something read off the server config at the point of use. The callers that have a
server config pass its value, which is what the code read before, so every
response keeps the destination it had. The peer fan-out builds its sync with a
nil server config, so anything derived from that config inside the conversion is
unavailable there; a parameter is reachable from the fan-out.
On the client side, Engine.Start takes the login response's PeerConfig. Nothing
reads it yet.
* Support per-peer lazy connection state and default proxy peers to lazy
* Classify forward targets from incoming config in lazy exclusion
* Set IsUserspaceBind mock so lazy manager starts in engine test
* Skip lazy exclude reconciliation when the set is unchanged
* Keep cached lazy flag when a sync carries no peer config
riccardom