Do not explicitly call RunMetadataResolver in case the pod namespace
label has not been retrieved yet (e.g., the pod informer has not yet
received the creation event for the pod), given that the same operation
is always guaranteed to be started immediately afterwards as well.
Moreover, this duplicate call can eventually cause the endpoint
regeneration state machine to go out of sync, leaving the endpoint
stuck in "waiting-to-regenerate" state forever.

Specifically, the above problem occurs due to the following sequence
of events:

1. A new pod gets created and scheduled onto a node, in turn eventually
   leading to an endpoint creation API request.
2. When the request is processed, the pod informer has not yet received
   the pod creation event, hence causing the pod retrieval to fail.
3. At this point, the set of identity labels only contains the init one
   (because we couldn't retrieve the pod labels), hence triggering the
   first call to ep.RunMetadataResolver. In turn, this starts a controller
   in the background (not blocking, as the second parameter is false),
   which attempts to retrieve the labels again, sets the identity (using
   the init one in case of retrieval failure) and triggers the endpoint
   regeneration. The endpoint first transitions into waiting-to-regenerate
   state); eventually, the regeneration starts to be processed, and the
   endpoint moves into regenerating state.
4. ep.RunMetadataResolver is called a second time; this step would
   normally be blocking (the second parameter is true), but in case
   the labels are already correct due to the previous call to the same
   function, no regeneration would be required, eventually returning
   regenTriggered = false;
5. Given that regenTriggered is false, the regeneration is triggered
   again immediately afterwards [1], transitioning the endpoint into
   waiting-to-regenerate state again. It is important to note that in
   this case we propagate the endpoint creation context as part of the
   regeneration event, rather than using the endpoint context. This
   appears correct, but ends up being problematic in this specific case.
6. In background, the initial regeneration triggered in 3. completes
   correctly. The endpoint is attempted to be transitioned into ready
   state, but that's skipped (correctly) because another regeneration
   has been scheduled subsequently (in 5.). At the same time,
   WaitForFirstRegeneration [2] unblocks (given that the regeneration
   completed), letting the endpoint creation API request to terminate.
   This, in turn, causes the associated context to be canceled.
7. At this point, there's still the endpoint regeneration triggered in
   5. that needs to be executed; however, depending on the timing, the
   handling may be aborted in [3], given that the context has just been
   canceled; while this would normally indicate that the endpoint is
   terminating, hence not causing any problems, in this case it leaves
   the endpoint stuck into the waiting-to-regenerate state, from which
   it will never recover (as all subsequent regeneration triggers would
   be treated as duplicates).

Dropping the duplicate call to ep.RunMetadataResolver prevents this
problem, as it ensures that we don't unnecessarily trigger a second
regeneration associated with the API context. The fallback regeneration
should actually never required when operating in Kubernetes mode,
because ep.RunMetadataResolver will always cause a new identity to
be assigned to the endpoint, in turn triggering regeneration.

[1]: https://github.com/cilium/cilium/blob/a9bcb0cb3858749f584c48cf5922f060c5f5871e/daemon/cmd/endpoint.go#L569-L582
[2]: https://github.com/isovalent/cilium/blob/a9bcb0cb3858749f584c48cf5922f060c5f5871e/daemon/cmd/endpoint.go#L573-L575
[3]: https://github.com/cilium/cilium/blob/a9bcb0cb3858749f584c48cf5922f060c5f5871e/pkg/endpoint/events.go#L64-L71

Signed-off-by: Marco Iorio <marco.iorio@isovalent.com>