Report config push failures as Events

[rainest]

What this PR does / why we need it:

Adds tag information indicating the Kubernetes resource that resulted in a Kong resource.

Adds parent information to Services, to indicate which route initially added them. Mostly for multi-service backends, which we cannot tag with a single Kubernetes Service and need to tag with whatever GWAPI route added them.

Handles and uses the Kong 3.2 flattened error response for DB-less pushes.

Generates Events associated with problem resources when a DB-less push fails.

Which issue this PR fixes:

Best-effort solution for FTI-4350. Although we cannot reject such failures up front, we can make their cause more accessible than the status quo (controller logs mention the Kong entity at fault, but not the Kubernetes resources). Users can query events by type and see the Kubernetes resource in the Event data.

Special notes for your reviewer:

WIP commits left as-is. This will eventually be squashed, but the history is too long and complicated to rebase into a more cohesive set of commits. The individual commits may be somewhat more useful to understand history than squashing up front. Apologies for the size, the original mandate was to produce a working PoC up front, so the issue was not broken into smaller chunks.

The addition of Kubernetes resource tags broke a large number of unit tests that want to compare complete objects. The tag contents are irrelevant to those tests, but break Equal(). My updates to unit tests either null out the tags before comparison or add the tags to the expected objects, depending on which was easier for the individual test. This (and similar broad changes in the past) requiring so many changes suggests we should amend these tests to instead compare relevant fields instead of complete objects, but reviewing which fields are relevant and refactoring all tests is a large effort. Depending on the unit test, not all would add useful tags anyway (since they're not starting from a complete Kubernetes resource).

Integration tests require running against kong/kong:master-alpine to check this functionality, as 3.2 is unreleased.
event_generation_manual.txt is a local run. rainest#189 uses a modified CI job to run this elsewhere (the nightly test job was already a bit broken and, I expect, now much more broken due to lack of updates to keep up with the main CI test job).

PR Readiness Checklist:

Complete these before marking the PR as ready to review:

• the CHANGELOG.md release notes have been updated to reflect any significant (and particularly user-facing) changes introduced by this PR

[rainest]

https://github.com/rainest/kubernetes-ingress-controller/actions/runs/4148511218/jobs/7176623721 from fork run rainest#193 is this against current Kong master.

I was trying to think of a way to make the master image runs conditional (we can either include or exclude them via labels on PRs), but between limitations in Actions and our current matrix system I'm not sure we can. My attempts do run it against latest master, but they always do so. Skipping that without the appropriate label didn't work as I'd hoped, and even if it did I think the matrix means it'd do an extra test run, since it should skip the image override step (it's not even doing this), but that would then result in it still running the matrix entry with the standard image. Ideally it'd not run the extra job at all if it's unnecessary.

[randmonkey]

LGTM in general, but I want to know that what happens if POST /config error happened in the following situations:

• Kong version <= 3.1
• failed to connect to kong admin API

[rainest]

@randmonkey

LGTM in general, but I want to know that what happens if POST /config error happened in the following situations:
Kong version <= 3.1
failed to connect to kong admin API

Nothing new. This unmarshals errors from POST /config into a struct that has an omit_empty field for the new flattened_errors field, so if that's not present (either because older Kong versions don't have it or because it's some other class of error), the struct field is empty the code that checks if there are ResourceErrors to process sees none and skips that processing. We then proceed with the error handling we already had (logging a failure and returning an error back up through the sync loop).

[czeslavo]

🚢