This commit simplifies the DeletionFallbackClient usage and handling of
endpoint deletion requests. With this patch the constructor now returns
the client object without performing any initialization.
The `EndpointDeleteMany` method is directly used by callers to request
endpoint deletion which is processed according to below flow:

```mermaid
flowchart TD
    A[DeletionFallbackClient] -->|EndpointDeleteMany| B[Get Or Connect Cilium API]
    B -->|Success| D[Request Endpoint Delete]
    B -->|Failure| E{DeletionQueue Lock}
    D -->|Success| OK{Return OK}
    D -->|Failure| E
    E -->|Acquired| F[Persist Deletion Request]
    E -->|NotAcquired| L[AcquireLock]
    L -->|Success| B
    L -->|Failed| NotOK
    F -->|Success| OK{Return OK}
    F -->|Failed| NotOK{Return Error}
```

Signed-off-by: Deepesh Pathak <deepesh.pathak@isovalent.com>

Signed-off-by: Deepesh Pathak <deepesh.pathak@isovalent.com>

Signed-off-by: Deepesh Pathak <deepesh.pathak@isovalent.com>

This commit adds a readiness precheck to certain endpoint subsystem APIs
like Put, Delete, Patch. This check ensures that endpoint APIs are not
exposed to external components like CNI till all dependencies are ready.
Currently this includes:

1. Endpoint Delete
  * Endpoint Delete APIs are only exposed once the state restore is complete.
  This ensures that all delete operations always see full state of endpoint
  manager so as to avoid any missed deletes.

2. Endpoint Put/Patch
  * Endpoint Update APIs are guarded by DeletionQueue fence. These apis are
  only exposed once the offline deletion queue is processed by the agent.
  Since the processing of endpoint Delete and Add operations is async,
  this check ensures that we don't delete an active endpoint if there is a
  delay in replaying the offline delete queue.

Signed-off-by: Deepesh Pathak <deepesh.pathak@isovalent.com>

Signed-off-by: Deepesh Pathak <deepesh.pathak@isovalent.com>

…tion

Signed-off-by: Deepesh Pathak <deepesh.pathak@isovalent.com>

This commit changes how other components(daemon) waits on initial policy
computation for an endpoint. Instead of directly relying on the
`InitialEnvoyPolicyComputed` channel in an endpoint object, we now expose
a method for existing callers to block on initial policy computation.
`WaitForInitialPolicy` method on endpoint object waits on either initial
policy to be computed or endpoint to be deleted. This makes sure that
callers don't wait on policy computation indefinitely in cases where
endpoint is deleted before initial regeneration is completed.

This fixes an issue in cilium during endpoint restore where a restored
endpoint is deleted before regeneration when processing the offline
deletion queue.

Signed-off-by: Deepesh Pathak <deepesh.pathak@isovalent.com>

This reverts commit 62c81af.

Signed-off-by: Deepesh Pathak <deepesh.pathak@isovalent.com>