This commit reworks the two test for the WireGuard agent
`TestAgent_AllowedIPsRestoration` and `TestAgent_PeerConfig` while
preserving the tested logic. The main changes are as follows:

1. add an `assertAllowedIPs` also inside `TestAgent_PeerConfig` to slim
   down the n. of assertions: expected allowedIPs are now provided as list
   rather than having to manually test them on multiple lines.
2. introduce `type config struct` to hold the test parameters and
   `type expectation struct` to hold expected allowedIPs for a given peer:
   this is useful for subsequent commits, as we can reuse the testing logic
   that we currently have in the agent for different routing modes. In fact,
   we are trying to slim down the set of tracked allowedIPs in WireGuard,
   and this can lead to different agent behaviors depending on the
   underlying datapath configuration (tunnel, native without CIDRs, native
   with CIDRs, etc.). This new struct defines, other than the name of
   a given test and the routing mode, the expectation that must be met
   everytime invoking the apposite `assertAllowedIPs` in the two tests.
   A single expectation is a `[]*net.IPNet` representing all the
   allowedIPs that we expect to be present on a given assertion.
3. modified the two tests according to (2): the only current behavior of
   the agent is the native routing mode in which we track all IPs.

Signed-off-by: Simone Magnani <[email protected]>

Whenever we call the `updatePeerByConfig` in the Wireguard agent, we always
perform `ConfigureDevice` even in case there are no new allowedIPs to insert.
This could result in many unneeded syscalls being used anyway, such as when:

* finishing restoring IPs for a peer with no IP to be removed;
* handling an IPCache delete event with no new IP to add.
* periodic NodeValidateImplementation with no changes to the node pubkey/IPs

The 1st ever call to `UpsertPeer()` will always configure the device, as
nodeIPs are new. On the other hand, when restoring allowedIPs or when
handling an IPCache event, we can avoid configuring the device when no
relevant changes are recorded. Note that IPs that needs to be removed
would be correctly handled and removed in any case.

Signed-off-by: Simone Magnani <[email protected]>

This commit adds an hidden flag `WireguardTrackAllIPsFallback`.
Subsequent commits will try to modify the logic of the agent depending
on the underlying routing mode, expecting significant changes mainly when
in tunneling. This flag, which is false by default, is introduced in case
the new changes break connectivity that we did not foresee. If that is the
case, reinstalling Cilium with `wireguard-track-all-ips-fallback` should
restore the previous known agent behavior, which is to add all IPs into
its allowedIPs regardless the datapath config.

Signed-off-by: Simone Magnani <[email protected]>

In the WireGuard agent, we constantly update peers configuration whenever
IPs are being upserted/removed, other than keeping track of peers' nodes
IPs. This results in having a multitude of entries both in our userspace
AllowedIPs map and in the kernel trie, requiring more memory and also
computation on each lookup.

Let's keep the datapath configuration in the loop, so that we can avoid
tracking addresses when not needed. Node IPs of a peer are always tracked
to include scenarios such as node encryption, overlay and mixed IPAM modes.
That said, the following two routing scenarios have been identified:

1. Tunnel: when using overlay, we don't need to track all IPs, since for
   pod-to-pod connections we would use node IPs in the overlay traffic.
   Therefore, no further addresses is needed, so we don't event add
   the agent as a listener for IPCache events: nodeIPs changes will
   always be handled by the UpdatePeer() logic. Another advantage of this
   approach is that IPCache updates don't need to be locked by the agent.
2. Native routing: similarly as we were doing before this patch,
   in this configuration we keep track of each IP, since we don't have
   other ways of knowing a-priori from which set of addressed a node
   will receive the traffic. Configurations such as IPAM legacy, Azure,
   AlibabaCloud, "crd" mode, delegated, would fall into this scenario.

Restoration logic when switching from tunneling to native routing should
work without problems: here the only IPs restored from allowedIPs are
node IPs, which are either kept if equal to the new ones or removed in
case they changed. Upon restart, the agent tracks all pod IPs from IPCache.

Restoration logic when switching from native routing to tunneling should
not cause problems: for the whole duration of the restoration until
`RestoreFinished` is called, we would see in the allowedIPs both the
new nodeIPs and all the restored ones. In this case, the agent would not
subscribe to IPCache changes/state, therefore it will not track these
pod IPs anymore, leading to their removal once restoration has finished.
The new pod-to-pod connectivity should go through the tunnel, so nodeIPs
must be sufficient, but if we do see failures we can use the new flag
`WireguardTrackAllIPsFallback`` (`wireguard-track-all-ips-fallback`): it
serves to preserve the old behavior of the agent even with this patch on.

In addition, this commit adds to the current agent tests the tunneling
scenario, both considering the default behavior and the fallback one when
WireguardTrackAllIPsFallback is provided. The fallback testing is intended
for tunneling mode only, as in native routing mode we would already have
the old behavior of the agent.

Fixes: cilium#35331

Signed-off-by: Simone Magnani <[email protected]>