tests: add integration test for kong2kic

[battlebyte]

• Granular tests based on each resource type
• Integration test deploys generated manifests to k8s cluster
• Refactor code to add annotations for tags
• Fix consumer group plugin bug
• Inform plugin attributes: enabled, runon, ordering, protocols
• Generate external service when host is informed and there is no upstream match

[codecov-commenter]

Codecov Report

Attention: Patch coverage is 54.03509% with 131 lines in your changes are missing coverage. Please review.

Project coverage is 23.34%. Comparing base (ce8628e) to head (d87663c).

Files	Patch %	Lines
kong2kic/route.go	27.77%	42 Missing and 10 partials ⚠️
kong2kic/consumer.go	21.21%	21 Missing and 5 partials ⚠️
kong2kic/service.go	69.84%	15 Missing and 4 partials ⚠️
kong2kic/global_plugin.go	52.94%	13 Missing and 3 partials ⚠️
kong2kic/consumer_group.go	71.42%	7 Missing and 3 partials ⚠️
kong2kic/ca_certificate.go	69.23%	3 Missing and 1 partial ⚠️
kong2kic/certificate.go	71.42%	3 Missing and 1 partial ⚠️

Additional details and impacted files

@@            Coverage Diff             @@
##             main    #1235      +/-   ##
==========================================
+ Coverage   21.46%   23.34%   +1.88%     
==========================================
  Files          53       53              
  Lines        5400     5616     +216     
==========================================
+ Hits         1159     1311     +152     
- Misses       4149     4189      +40     
- Partials       92      116      +24     

☔ View full report in Codecov by Sentry.
📢 Have feedback on the report? Share it here.

[rainest]

Is there a command to regenerate output? kong2kic/testdata/README.md doesn't mention one and I don't see an existing make target for it. It's unclear how you should update expected output if input or transform code changes. If the answer is "by hand", it shouldn't be.

I don't much love golden output tests for purposes other than showing what a diff is, and they're especially iffy if presented in isolation and without comment on what a particular input/output test is supposed to demonstrate. I'd prefer having more focused units around "field X in input transforms to fields Y+Z in output as expected" as a base, with golden full input/output comparison as backup material to highlight any differences we may not have accounted for in the units.

Golden-style tests end up being particularly challenging for tools that expect to support multiple versions of adjacent software, where we end up with things like this sync test change that are essentially 98% the same as some other version's test case, but require significant input/output duplication because the surrounding checks aren't flexible enough to handle the 2% that is different between versions.