Add an ingress uid label to tunnels

[jrobsonchase]

Resolves #291

What

Add a k8s.ngrok.com/ingress-uid label to tunnels created by the
ingress controller to uniquely identify them among multiple ingress
controller instances.

How

Plumb the full ingress object down to the method to create ngrok tunnel
lables, and add the UID from that. The ingress UID should be stable as
long as the object exists in k8s (citation needed?), so we don't have to
worry about unexpected recreate thrashing as a result of it changing.

Breaking Changes

Shouldn't be any. After the ingress controller is redeployed, a
difference should be detected between the desired and actual tunnel
state, and things should be recreated with the new labels as expected.

[jrobsonchase]

Current dependencies on/for this PR:

• main
  • PR Add an ingress uid label to tunnels #293 👈

This comment was auto-generated by Graphite.

[bobzilladev]

Hopefully r.statusID wasn't actually ever nil there.

[euank]

Just so we're aware, this does have a functional difference that could matter for limits.

To explain what I mean, let's look at the following scenario:
You have one service (my-app) listening on port 80, and you have 5 ingresses for it (ing1.myapp.ngrok.io through ing5.myapp.ngrok.io).
Before, that would result in 1 tunnel with the labels namespace: default, service: my-app, port: 80).
After this change, since there's N different ingresses, it's now 5 tunnels, which could get you closer to your session tunnel limit.

An alternative to this would be using the namespace UID, or using the service UID, both of which would be shared in more cases.
I feel like the service UID matches most closely with the existing intent of the labels.

All that said, I think this is probably fine, and like longer term we probably need to rethink this a bit regardless (i.e. the coupling of service and tunnel is a slightly off abstraction, and really we need to be pulling the EdgeID out of the tunnel header we get sent by the server).
I think the service UID probably fits a little better, but I could also be missing something there

[jrobsonchase]

The ingress UID maps most cleanly to our current tunnel ownership model. We're also setting the tunnel owner as the ingress, so I don't think it was ever the intended behavior for a tunnel to be usable by multiple ingresses that just so happened to have the same labels.

@bobzilladev Well... it was, and I was getting panics 😅 Didn't dig much deeper into the underlying cause though.

[nikolay-ngrok]

This actually breaks the case where we have multiple ingresses in the same namespaces, defining routes leading to the same service. This is because we are creating multiple https edge routes, but a single tunnel, so the last one that marks the tunnel wins, leaving the rest unroutable.