don't require a detailsVpnAddr in a HostUpdateNotification

[JackDoan]

If we don't use this information, don't put it on the wire, so we then do not have to check it. If this does indeed have a use, we can just remove the comment and close this

[nbrownus]

Places where we set Details.VpnAddr

• handleHostQuery where we prep a lighthouse response to a non lighthouse host.
• handleHostUpdateNotification this currently results in a NebulaMeta_HostUpdateNotificationAck back to the host that sent the update which is a noop.
• innerQueryServer where we send NebulaMeta_HostQuery to lighthouses.
• sendHostPunchNotification where we send NebulaMeta_HostPunchNotification to responder hosts after an initiator sent a NebulaMeta_HostQuery about them to a lighthouse. Line 1351 could be an interesting follow on to this PR.
• SendUpdate where we send NebulaMeta_HostUpdateNotification to the lighthouses with our current known underlay addresses in it.
• resetMeta which just zeroes the shared memory between lighthouse requests

Looks like all is well!

Side note, the unlockedSetV4 and unlockedSetV6 need to be updated to deal with the known vpnAddrs instead of just the current one being passed around to completely cover the allow lists cases.

Site side note, that cat is out of the bag and I only bring it up because of #1464, since it looks like the primary addr choice isn't entirely sufficient, we could change the proto definition for NebulaMetaDetails.VpnAddr to be a repeated field and have the lighthouse always inform the remote of all known vpn addrs for a host at that point in time. No doubt it will create other problems but it might also short circuit some of the issues around choosing a primary vpn addr.

[JackDoan]

Side note, the unlockedSetV4 and unlockedSetV6 need to be updated to deal with the known vpnAddrs instead of just the current one being passed around to completely cover the allow lists cases.

Site side note, that cat is out of the bag and I only bring it up because of #1464, since it looks like the primary addr choice isn't entirely sufficient, we could change the proto definition for NebulaMetaDetails.VpnAddr to be a repeated field and have the lighthouse always inform the remote of all known vpn addrs for a host at that point in time. No doubt it will create other problems but it might also short circuit some of the issues around choosing a primary vpn addr.

I kind of like this idea -- we could also send a whole hostQueryReply per IP on a query, but that sounds much worse I think?

[nbrownus]

Yeah sending individual replies per vpnAddr will confuse the situation more than anything I think, the client host has no way to correlate the answers into a single RemoteList.

[wadey]

approved, although anyone already using V2 certs will need to be careful to deploy this change to their lighthouses before updating their clients.