fix: panic in consumer sort func

[shaneutt]

What this PR does / why we need it:

Small fix to prevent a panic when an empty username is given for a KongConsumer.

Which issue this PR fixes

Fixes #550

PR Readiness Checklist:

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

[codecov]

Codecov Report

Merging #1658 (1525cf9) into next (f79e8ee) will decrease coverage by 0.14%.
The diff coverage is 0.00%.

❗ Current head 1525cf9 differs from pull request most recent head 18f5548. Consider uploading reports for the commit 18f5548 to get more accurate results

@@            Coverage Diff             @@
##             next    #1658      +/-   ##
==========================================
- Coverage   62.11%   61.96%   -0.15%     
==========================================
  Files          83       83              
  Lines        7319     7330      +11     
==========================================
- Hits         4546     4542       -4     
- Misses       2440     2454      +14     
- Partials      333      334       +1     

Flag	Coverage Δ
integration-test	61.96% <0.00%> (-0.15%)	⬇️

Flags with carried forward coverage won't be shown. Click here to find out more.

Impacted Files	Coverage Δ
internal/deckgen/generate.go	47.39% <0.00%> (-3.22%)	⬇️
internal/ctrlutils/ingress-status.go	48.67% <0.00%> (-1.21%)	⬇️
internal/ctrlutils/utils.go	88.46% <0.00%> (+1.92%)	⬆️

---

Continue to review full report at Codecov.

Legend - Click here to learn more
Δ = absolute <relative> (impact), ø = not affected, ? = missing data
Powered by Codecov. Last update f79e8ee...18f5548. Read the comment docs.

[rainest]

Does this indeed prevent all panics when submitting a no-username consumer? IIRC the deck code further down also panicked when we gave it one, so fixing the sort mechanism will just result in a panic at a different point in the code.

Instead, we probably want something like what we do for credentials missing required fields: if we know they will break later, we just log that they're invalid and don't add them to the list. That's ideally accompanied by an admission controller rule to reject them in the client, since logging alone isn't the most obvious UX.

If we do proceed with something like Kong/deck#246 eventually we will still want the sort in the controller to work properly, so a sort fix will future proof for that even if it's a no-op if we just drop no-username consumers for the time being. However, it should probably concatenate Username+CustomID rather than have a blanket behavior for any no-username consumer: you can have multiple no-username consumers with distinct custom IDs, and those consumers should sort consistently.

[shaneutt]

Yep you were right @rainest: my first attempt here was assuming that the consumer would be handled gracefully at the deck level, but after digging into that further it would panic there also.

Check out this new patch instead 👍

[rainest]

Ideally this would include an admission controller rule also, but eh, probably still worth avoiding the panic even without.

There's one remaining change that should probably go in; I'm pretty sure the IDs here aren't ever of use.