GH-311 gateway status instead of ocm api calls

[maksymvavilov]

What

Change in how we get information about clusters onto which we placed gateway. Instead of poking the OCM we now extract those from the GW CR itself.

Verification

1. Follow one of the submariner PoCs up to the point where you have gateway placed on the multiple clusters
2. Ensure that DNSRecords have endpoints set

closes #311

[mikenairn]

The main goal with this task was to remove the dependency on the OCM placement API in the dnspolicy controller and reconcilers. As this is, it's removed a small bit of it but not all. I'd start by removing this https://github.com/Kuadrant/multicluster-gateway-controller/blob/main/pkg/controllers/dnspolicy/dnspolicy_controller.go#L66 and see what breaks and make it work without it.

You probably need to process the status of a gateway and build up a map of clusters and it's addresses and iterate over that rather than calling the placer functions, also the attached routes info should be available in both cases directly from the gateway.

Listeners also need to be processed differently to take into account the two types of Gateway (Multi and single):

kubectl get gateway prod-web -n multi-cluster-gateways -o json | jq .status.listeners
[
  {
    "attachedRoutes": 1,
    "conditions": [],
    "name": "kind-mgc-control-plane.api",
    "supportedKinds": []
  },
  {
    "attachedRoutes": 1,
    "conditions": [],
    "name": "kind-mgc-workload-1.api",
    "supportedKinds": []
  },
  {
    "attachedRoutes": 1,
    "conditions": [],
    "name": "kind-mgc-workload-2.api",
    "supportedKinds": []
  }
]

And the object that represents a "Cluster" should be any GVK, rather than hard coded to an OCM "ManagedCluster". This is just a resource that has labels so can be anything, but will always be a "ManagedCluster" in MGC.

[maksymvavilov]

/hold

[maksymvavilov]

/label tide/merge-method-squash

[mikenairn]

Not ideal having to pass in all the addresses here just to work out if it's an MGC updated status we are dealing with or not. I can see why you have done it this way though, so maybe a better way of determining the type of Gateway we are dealing with, and the expected status, can be looked into later.

[maksymvavilov]

adding this to the stockpile of "fix later"

OUt of date

[mikenairn]

/lgtm
/approve

[openshift-ci]

[APPROVALNOTIFIER] This PR is APPROVED

This pull-request has been approved by: makslion, mikenairn

The full list of commands accepted by this bot can be found here.

The pull request process is described here

Needs approval from an approver in each of these files:

• OWNERS [mikenairn]

Approvers can indicate their approval by writing /approve in a comment
Approvers can cancel approval by writing /approve cancel in a comment