chore: extract code to new library

[rainest]

Following the extraction of v1.29.2 library code to a separate repository in Kong/go-database-reconciler#9, update deck module references to use that code's new home.

Remove copies of that code from the deck repo and clean up modules not used by the remaining packages in kong/deck.

As-is this PR relies on a commit hash module version for the new repo. We should merge Kong/go-database-reconciler#9 first, tag an actual version, and replace the temporary module version with that.

Removes codegen-related make targets, scripts, and CI configuration, as that does not interact with the remaining code here. I'm not sure how we were using the kong_json_schema.json output from one of those. There don't seem to be references here. Is there anything external we need to update with that having moved, or is kong_json_schema.json actually internal to the file package and Go code that imports it?

Golang and package upgrades appear to have broken several tests. This includes additional changes to address those:

The fatih/color module made changes in v1.16.0 that had the (maybe) unexpected side effect of removing spaces between arguments. AFAICT the insertion of c.Sprint() means that it calls doPrint() instead of doPrintln(). The former inserts spaces between non-string arguments only, whereas the latter inserts spaces between all arguments. There's no immediate need to upgrade this, so I just downgraded it back to v1.15.0, the version deck is currently using.

Something (dunno what, possibly the Golang upgrade?) changed how tests see deck output. This change was originally reporting errors due to actual output including color codes, whereas the expected output does not contain color codes. I think something in an older version was stripping those, since they are indeed present in the output and the tests never had anything to strip them before. I added a small MIT-licensed helper lib to just strip them, since I don't think we care about color in those integration tests and writing the codes into the expected strings is kinda annoying.

[codecov-commenter]

Codecov Report

All modified and coverable lines are covered by tests ✅

Comparison is base (f7e0a17) 32.86% compared to head (7893868) 5.94%.

Additional details and impacted files

@@            Coverage Diff             @@
##             main   #1109       +/-   ##
==========================================
- Coverage   32.86%   5.94%   -26.92%     
==========================================
  Files         103      31       -72     
  Lines       12851    3129     -9722     
==========================================
- Hits         4223     186     -4037     
+ Misses       8219    2933     -5286     
+ Partials      409      10      -399     

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

[GGabriele]

I'm not sure how we were using the kong_json_schema.json output from one of those.

This file pulled here and used as part of the input validation logic.

There's no immediate need to upgrade this, so I just downgraded it back to v1.15.0, the version deck is currently using.

Good call, thanks!

Something (dunno what, possibly the Golang upgrade?) changed how tests see deck output. This change was originally reporting errors due to actual output including color codes, whereas the expected output does not contain color codes. I think something in an older version was stripping those, since they are indeed present in the output and the tests never had anything to strip them before. I added a small MIT-licensed helper lib to just strip them, since I don't think we care about color in those integration tests and writing the codes into the expected strings is kinda annoying.

SGTM!

[rainest]

Okay, so the schema JSON should be part of the lib then AFAICT. Bumped to an actual go-database-reconciler tag, sorted out some module weirdness, should be good to go.

[bastantoine]

Hello, I just found out about this MR. The file kong_json_schema.json is referenced in the documentation of the DB-less and declarative config (under Declarative configuration format, search for "See the declarative configuration schema for all configuration options").

Could you update the documentation (here) to either remove the link, or bring back the reference file somewhere and update its location in the docs ?
Do you required an issue about this?

Fun fact, I was using this file yesterday, so imagine my surprise when I didn't found it this morning 😅.

Thank you!