Extend VirtualService/Gateway probing to HTTPS

[JRBANCEL]

In what area(s)?

/area networking

Describe the feature

#4734 introduces VirtualService/Gateway probing. The current implementation doesn't work when HTTP is disabled because it assumes that the Envoy pods can be probed directly over HTTP. In practice, knative-ingress-gateway is assumed to contain:

spec:
  servers:
  - hosts:
    - '*'
    port:
      name: http
      number: 80
      protocol: HTTP

meaning Envoy will accept HTTP traffic on port 80 for any host. Therefore, we can probe the dummy rule added in #4734.

Unfortunately, this is not always true because:

1. Customers can edit the Gateway manually (manual TLS)
2. Knative can edit the Gateway automatically (auto TLS)
3. Customers can disable HTTP entirely or restrict it to specific hosts

The current probing implementation has to be updated to probe using the real hosts and not the dummy probe host. See #5032 for a sketch of the required work. Probing requests will go through the real data path, Envoy will add a K-Route-Hash header containing the hash of the VirtualService/Gateway. If K-Network-Probe header is present, Queue-Proxy and Activator will return the value of K-Route-Hash in a header with HTTP 200, otherwise, will strip the K-Route-Hash header and process the request. This way, StatusProber can figure out what version of the VirtualService/Gateway is being used by Envoy.

Work Items

• 1) Queue-Proxy must handle probing requests New probe handling in Queue-Proxy & Activator #5159
• 2) Activator must handle probing requests New probe handling in Queue-Proxy & Activator #5159
• 3) Add ExpectsHeader Verifier to Prober New probe handling in Queue-Proxy & Activator #5159
• 4) Update StatusProber to probe through the real data path Handle HTTPS redirect, HTTPS, HTTP2 & custom ports in VirtualService probing #5223
• 5) Increase test coverage of non-default network configuration (HTTP only, no-HTTP & HTTPS, Redirect, etc...) Extend VirtualService/Gateway probing to HTTPS #5156