Currently, we're not tracking the CiliumBGPNodeConfig changes. We must
track it to recover from the nodeSelector conflict for example. Without
tracking it, the scenario like the following is possible:

1. NodeA is reffered from ClusterConfigA and ClusterConfigB. Currently,
   ClusterConfigB "owns" the node.
2. ClusterConfigB changed the nodeSelector. NodeA is no longer selected
   by ClusterConfigB.
3. ClusterConfigA suppose to create a new NodeConfig for NodeA, but the
   reconciliation was not triggered because we're not watching the
   NodeConfig changes.

Signed-off-by: Yutaro Hayakawa <yutaro.hayakawa@isovalent.com>

In the current implementation, we fetch the CiliumBGPNodeConfig for the
node twice in the update process. One is in the getMatchingNodes and
another is in the upsertNodeConfig. The former checks the owner
reference, but the latter does not.

As a result, if the NodeConfig cache is updated during those two, the
operator may not catch the fact that the NodeConfig is already owned by
someone else. And since we haven't watched the NodeConfig (see the
previous commit), the operator will never have a chance to update the
ConflictingClusterConfig condition. The concrete scenario would be:

1. ClusterConfigA and ClusterConfigB are created. Both selects the
   NodeA.
2. The operator reconciles ClusterConfigA and create a NodeConfig for
   the NodeA.
3. The operator reconciles ClusterConfigB next. In the getMatchingNodes,
   the operator didn't see the NodeConfig created by the reconciliation
   of the ClusterConfigA.
4. The NodeConfig cache is updated. However, it will not be notified to
   the operator since we don't watch the NodeConfig.
5. The operator calls upsertNodeConfig. It fetches the NodeConfig from
   the cache, but don't check the owner, so proceed with the DeepEqual
   check and since there was no diff, did nothing.
6. The reconciliation of ClusterConfigA and ClusterConfigB is done. The
   operator didn't see any conflict in this reconciliation cycle.
7. Since the NodeConfig cache update didn't trigger the reconciliation,
   the operator never notice the conflict until next reconciliation.

This issue doesn't appear if the cache update is done before
getMatchingNodes. The TestConflictingClusterConfigCondition was flaky
due to this undeterministic behavior.

This commit fixes the issue by combining the getMatchingNodes and
upsertNodeConfig and fetching NodeConfig only once in the upsert logic.

We made some cleanup for the existing logic as a part of this fix. Most
of them are identical, but we removed the adhoc retry in the
upsertNodeConfig and deleteStaleNodeConfig which is not required since
we have a retry.

Signed-off-by: Yutaro Hayakawa <yutaro.hayakawa@isovalent.com>