Multi Pool IPAM mode requires both an operator component as well as an
agent one. Currently, both components, despite being completely
separate, are kept under pkg/ipam/allocator/multipool.  Following the
structure of other packages, move all the operator related logic under
operator/pkg/ipam. This allows to recognize at a glance if a certain
portion of the code is part of the agent or part of the operator.

Signed-off-by: Fabio Falzoi <fabio.falzoi@isovalent.com>

The PooledAllocatorProvider interface was meant to abstract the use of
concrete pooled allocators (like multipool.Allocator) into the IP Pools
watcher. Since the multipool allocator is the only concrete
implementation, in order to reduce the complexity, remove the interface
and use the type directly.

Signed-off-by: Fabio Falzoi <fabio.falzoi@isovalent.com>

The ciliumNodeUpdateImplementation struct was meant to simplify the
interactions with the CiliumNode resource in each different IPAM
implementation (multi-pool, cluster-pool, ENI and so on).  Since all the
IPAM operator subsystem is now implemented as a hive cell and each IPAM
flavor has an independent implementation with a reference to the
dependecy-injected ClientSet, the abstraction is not useful anymore.

In order to simplify the multi-pool implementation, let's use the
ClientSet directly.  Moreover, this removes the redundant double check
for equality of the old and new version of the resource done with
DeepEqual when calling Update and UpdateStatus.

Signed-off-by: Fabio Falzoi <fabio.falzoi@isovalent.com>

Since those CIDRs will be used in the context of multi pool Resource
IPAM too, where we allocate addresses to DRA resources, let's avoid
mentioning "Pod" in the type name.

Signed-off-by: Fabio Falzoi <fabio.falzoi@isovalent.com>

Just like in the previous commit, those CIDRSlices will be used in
contexts where the allocated CIDRs will be used not by pods but by DRA
resources, therefore remove "Pod" from the type name.

Signed-off-by: Fabio Falzoi <fabio.falzoi@isovalent.com>

Just like the multi pool IPAM implementation, the auto creation of
CiliumPodIPPool feature can be split into two parts:

- a reusable set of functions to auto create pools based on a generic
  description
- a set of functions that finalize the creation of the pools in a
  specific kind of k8s object

While the first part could be reused for auto creation of multi pool
Resource IPAM pools too (that is, for CiliumResourceIPPool objects), the
second one implements the creation of pools specific for multi pool Pod
IPAM, namely CiliumPodIPPool objects.

The commit move the pod specific part into the multi pool cell for Pods
IPAM.

Signed-off-by: Fabio Falzoi <fabio.falzoi@isovalent.com>

This allows to reuse the code to handle pool events in multipool package
in the upcoming multi pool Resource IPAM too.

Signed-off-by: Fabio Falzoi <fabio.falzoi@isovalent.com>