Infer appropriate Kong route snis value from Ingress contents automatically

[rainest]

As a user I'd like KIC to fill in the snis field of a created route from the context of the ingress resource, so that the user does not need to specify the SNIs manually.

Historical context (the root cause for this not having been implemented back then seems to be resolved now):

Draft feature request to restore the automatic route snis population removed from #863.

We should revisit this once Kong/kong#6425 is fixed. However, the exact shape of this feature will depend on that fix, so for now this is a stub feature request with the original automation code for reference. That code "works" in the Kong <=2.2 world, but the effects of it working are bad. As such, we shouldn't actually develop any such automation for those versions.

Once we have new Kong router SNI behavior to work against, we should also add an E2E test, as testing this sort of automation effectively with Go tests alone probably isn't possible: it's very dependent on interactions with the Kong proxy vis a vis user expectations, and unit tests can't express either of those things.

Acceptance criteria

• for an HTTPS ingress configuration, KIC fills in the snis of a created route.
• integration tests for the SNI case are implemented (verifying that the SNI parameter of the created routes is functional)

[rainest]

git-show of the old commented code: auto-sni.diff.txt

It's a diff, but Github has asinine rules about allowed file extensions because MIME-sniffing is impossible, so it's a .txt.

[stale]

This issue has been automatically marked as stale because it has not had recent activity. It will be closed if no further activity occurs. Thank you for your contributions.

[mflendrich]

Recent versions of core are capable of supporting these inferred values.
The implementation would need to be a no-op for older versions of Kong (@rainest says 2.2.1 is the first version that can support this).

[shaneutt]

Closing as stale since the last comments are almost a year old. If there's still interest in following up on this however lets re-open/re-assess.