atenet-egress: refuse an actor's own CONNECT with 403 - #2721

The egress gateway tunnels one CONNECT: the one atunnel wraps the actor's
traffic in, on the outer chain. A CONNECT the actor sends itself -- what a
client configured with a forward proxy sends first, in the clear or inside
TLS -- arrives as a request inside that tunnel. docs/egress-traffic.md says
the actor gets 403 Forbidden for it, but nothing refused it.

The request filter evaluated it like any other request, on its authority's
host and the port the actor dialed, and an allowing policy let it through.
Only the route table stopped it: every inner route matches a path prefix and
a CONNECT has none, so Envoy answered 404. The answer depended on how the
routes happen to be written, and the policy filter had already said yes.
Honoring it would police the authority's host on the dialed port while
tunneling to the port the authority names.

The request filter now refuses a CONNECT on both inner legs with 403 and
"CONNECT egress is not supported", before identity and policy, as it does
WebSocket upgrades.

Two networking e2e tests cover it: the actor sends a CONNECT cleartext on a
conventional proxy port, and inside TLS on 443 through the gateway's
interception, each to an origin that answers any CONNECT 200 and to the
gateway's own Service. The 403 and body the actor sees cannot be the
origin's, so the gateway refused the CONNECT before it reached anything
that would have accepted it; a 2xx is reported as an opened tunnel.

To send it, the egress demo gains POST /connect, which dials a proxy,
optionally completes a TLS handshake with it, sends one CONNECT and reports
the answer without waiting on a body a 2xx never carries. testserver's http
subcommand gains --accept-connect, so an origin can stand in for a proxy.