Add api to generate endpoints

[maksymvavilov]

Moving logic that generates endpoints from the kuadrant-operator repo to the DNS-operator.
Also transfer applicable test cases and extend them a bit to cover a few edge cases since it is a unit testing and it is cheap.
There is a bump in the GO version - gatewayAPI requires it. It is debatable if we should be using Gateways in our API. An alternative would be to use addresses and labels in our "custom" struct and have a parser on the kuadrant-operator side. Just like there is a Routing struct to avoid policy usage.

[mikenairn]

IMO, the builder pattern would be better adopted if you use it to build the more complicated resources we actually care about (endpoints and/or dnsrecords) rather than just a fairly simple resource(It's just adding simple values to the struct) to pass to another function. This can also be done without modifying so much of the existing code if you stick to the idea of wrapping a kubernetes resource that represents the target which will have the metadata attributes for geo and weight applied, and is used to generated the likes of names and hashes that are used throughout the generation of loadbalanced endpoints.

Added an example of what a builder API for the endpoints could look like here, and also maybe how it could be used for a dnsrecord builder here .
Considering we might want to change the GVK of the record being generated by the kuadrant operator in the future, the endpoint builder is the most important one, and needs to be something we can use on it's own i.e. Not just part of a dnsrecord builder.

[maksymvavilov]

I also moved integration tests from controller to test/integration to avoid import cycles.

[mikenairn]

I also moved integration tests from controller to test/integration to avoid import cycles.

What exactly was causing a cyclic import? I can't see any obvious reason why you would get one, but if you are could it be a sign of a bad API design somewhere(packages that depends on the wrong things)?

I'm not completely against the idea of moving the current controller tests to an integration pkg under tests for the right reasons, we have done this in other repos, but i would do that in it's own PR if at all possible.

[maksymvavilov]

I also moved integration tests from controller to test/integration to avoid import cycles.

What exactly was causing a cyclic import? I can't see any obvious reason why you would get one, but if you are could it be a sign of a bad API design somewhere(packages that depends on the wrong things)?

I'm not completely against the idea of moving the current controller tests to an integration pkg under tests for the right reasons, we have done this in other repos, but i would do that in it's own PR if at all possible.

It was due to the generated deep copy in the API package. My mistake, corrected and moved the tests back. Will be more attentive next time

[maksymvavilov]

@mikenairn I've changed the PR to accommodate the DNS Policy rework. Now there should be no need to do anything after the simplification of the policy

[mikenairn]

I think this looks fine, and looking through the code and comparing with the current kuadrant operator (getSimpleEndpoints and getLoadBalancedEndpoints) looks like it should work as expected.

[maksymvavilov]

I think this looks fine, and looking through the code and comparing with the current kuadrant operator (getSimpleEndpoints and getLoadBalancedEndpoints) looks like it should work as expected.

Thanks!