Prior to this change, there were two possible ways a newly-allocated
identity would be added to the SelectorCache. The first was via the
ipcache, which allocates with `notifyOwner: false`, taking the
responsibility of propagating updates directly.

The IPCache first updates the SelectorCache, then triggers incremental
policy map updates on all endpoints. This works well.

Alternatively, an identity could be allocated by the global allocator.
In this case, `notifyOwner: true` was passed, and the allocator itself
took responsibility for updating the SelectorCache. This would
regenerate all endpoints, rather than merely applying incremental
updates. This also works, but is wasteful.

Finally, if a remote node allocates an identity, this will be
synchronized via the Allocator backend, sent on a watch channel,
inserted in to the SelectorCache, and all endpoints will be regenerated.

Regenerating all endpoints is quite wasteful; we have a functional
incremental policy update mechanism that exactly handles this case.
There were previously issues wherein Envoy would lose updates, but those
have been fixed. So, change it so *all* identity updates only trigger
incremental updates. Additionally, batch changes so we don't flood
endpoint locking.

Finally, when an identity is allocated by this node, we will process
this new identity twice: once on allocation, and once when the remote
backend gets the watch event. Add some de-duplication so we don't
needlessly process events.

Signed-off-by: Casey Callendrello <[email protected]>

A previous commit stopped regenerating all endpoints on identity
allocation, which was wasteful. However, it is still useful to have
periodic state reconciliation, in case a configuration edge is somehow
missed.

So, this adds an explicit controller in the EndpointManager that
periodically regenerates all endpoints. By default, the interval is 2
minutes, but it is configurable.

Signed-off-by: Casey Callendrello <[email protected]>

These metrics are not interesting:
1. It incremented a metric labeled with "policy update", which is
   confusing.
2. It ignored the asynchronous nature of endpoint regeneration, so the
   reported duration is incorrect.

Signed-off-by: Casey Callendrello <[email protected]>

The PolicyUpdater is a small trigger that batches requests to regenerate
all endpoints. Now that there is a controller for this directly in the
EndpointManager, we can remove this additional trigger.

Signed-off-by: Casey Callendrello <[email protected]>

The metrics `cilium_triggers_policy_update_total` and
`cilium_triggers_policy_update_folds` have been removed. They were never
particularly accurate, as this trigger was only used when auxiliary
resources such as CiliumEnvoyConfigs were updated, rather than actual
policy updates. Furthermore, the measured duration was incorrect as
the actual updates were asynchronous.

Signed-off-by: Casey Callendrello <[email protected]>