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 72.02680% with 167 lines in your changes missing coverage. Please review.

Project coverage is 28.17%. Comparing base (5f84270) to head (0558aba).

Files with missing lines	Patch %	Lines
kong2kic/route.go	70.76%	25 Missing and 13 partials ⚠️
kong2kic/upstream.go	74.07%	25 Missing and 10 partials ⚠️
kong2kic/utils.go	55.10%	14 Missing and 8 partials ⚠️
kong2kic/consumer_credentials.go	75.58%	18 Missing and 3 partials ⚠️
kong2kic/consumer_group.go	70.83%	8 Missing and 6 partials ⚠️
kong2kic/global_plugin.go	57.14%	9 Missing and 3 partials ⚠️
kong2kic/service.go	83.56%	6 Missing and 6 partials ⚠️
kong2kic/consumer.go	76.19%	3 Missing and 2 partials ⚠️
kong2kic/ca_certificate.go	66.66%	3 Missing and 1 partial ⚠️
kong2kic/certificate.go	69.23%	3 Missing and 1 partial ⚠️

Additional details and impacted files

@@            Coverage Diff             @@
##             main    #1235      +/-   ##
==========================================
- Coverage   29.14%   28.17%   -0.98%     
==========================================
  Files          59       61       +2     
  Lines        5215     5061     -154     
==========================================
- Hits         1520     1426      -94     
+ Misses       3587     3512      -75     
- Partials      108      123      +15     

☔ 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.

[hbagdi]

Closing this due to lack of activity. Please re-open if needed.

[battlebyte]

@hbagdi I will implement some of the suggestions shortly.