Update the TestUpdatePodLabels test to correctly specify the expected
resource version during updates, in preparation for extending the fake
client to actually enforce optimistic concurrency control.

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

Update the bgp tests to correctly specify the expected resource version
during updates, in preparation for extending the fake client to actually
enforce optimistic concurrency control.

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

Update the UpdateObjects helper to use the [ObjectTracker.Patch],
instead of [ObjectTracker.Update], in preparation for the subsequent
commit that will make the latter implement optimistic concurrency
control, and validate resource version mismatches, which is not
required in this context.

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

Currently, the object tracker is affected by a bug that causes the
resource version to not be set on creation or update if the object
does not have the [metav1.TypeMeta] set. Indeed, in that case, the
function updating the TypeMeta creates a deep copy of the object,
causing operations performed via [meta.Accessor] to act on the old
copy, and not have effect. Let's get this fixed by changing the
[fillTypeMetaIfNeeded] function to not create a deep copy, given
that it already operates on a copy of the original object.

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

Currently, the statedb object tracker backing the fake kubernetes client
used for testing purposes does not respect resource versioning, and allows
update operations to succeed regardless of the provided resource version.
While convenient for the `k8s/update` command itself, this approach is
problematic in case of controllers acting on the same resources, as it
can lead to objects being unexpectedly reverted to incorrect versions,
due to the missing optimistic concurrency control.

Let's get this fixed by extending the update implementation to additionally
compare the resource version of the stored and provided objects, and reject
the update in case they do not match, as the real Kubernetes API Server
would do. By default, the k8s/update command still ignores the provided
resource version, letting the update succeed regardless: this matches the
desired behavior in the vast majority of the tests, and avoids the need
for complex operations to set the expected resource version. Still, if
necessary, the stricter behavior can be enabled via the dedicated flag.

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