endpoint: Fix realized state corruption when initial policy regeneration fails
endpoint: Fix realized state corruption when initial policy regeneration fails

When an endpoint regeneration calculates policy for the first time, the policy
map is created. Up to now, the regeneration function queued a deferred function
that, on error, deleted the policy map again. If the endpoint generation failed
*after* the policy map content was already successfully synchronization, the
removal of the policy map result in a flush of the policy map content without
resetting e.realizedMapState which in turn would make e.syncPolicyMap() believe
that the desired state was already fully realized when the BPF map itself was
flushed. This would result in the BPF map being out of sync with what is
believed to be the realized state.

There is no need to defer the deletion of the map if the regeneration fails,
the policy map can remain in the endpoint. It will get reused in the next
regeneration attempt and will eventually get deleted when the endpoint is
removed together with all other BPF maps tied to the endpoint.

Similarly, if the policy map is removed for some reason, the regeneration does
re-create the map but did not reset the e.realizedMapState and thus would never
write to the map. Resolve this by always resetting the realizedMapState when
the policy map is created.

Signed-off-by: Thomas Graf <5f50a84c1fa3bcff146405017f36aec1a10a9e38@cilium.io>

tklauser/cilium,scanf/cilium,michi-covalent/cilium,tgraf/cilium,scanf/cilium,cilium-team/cilium,tgraf/cilium,scanf/cilium,cilium/cilium,tklauser/cilium,cilium/cilium,tklauser/cilium,michi-covalent/cilium,cilium/cilium,tklauser/cilium,cilium/cilium,tgraf/cilium,tgraf/cilium,cilium-team/cilium,scanf/cilium,scanf/cilium,cilium/cilium,tgraf/cilium,scanf/cilium,scanf/cilium,michi-covalent/cilium,michi-covalent/cilium,tklauser/cilium,michi-covalent/cilium,tgraf/cilium