router: Move from Host header to explicit headers for actor and atespace

[Keith Mattix II (keithmattix)]

This PR is purposefully controversial to try and encourage movement on the DNS issue (#445).

There has been an emerging consensus that substrate is not a system that we expect end-users to interact with directly; we can assume a higher level orchestrator is acting on the user's behalf to program substrate. Therefore, our networking scheme does not need to utilize the HOST header to encode the (actor name, atespace) reference tuple. This PR encodes that same tuple as two distinct headers: x-ate-actor-name and x-ate-atespace. We expect the higher order system originating substrate requests to be able to set these headers and remove any need for us to rewrite DNS. Note that this also applies to actor-to-actor requests: atunnel is originating CONNECT to the egress PEP, so when addressing another actor, it can set the requisite headers in the CONNECT request and the PEP can know to forward them to the router.

NOTE: CONNECT vs. direct HTTP (#1208) is a similar conversation; I see no reason not to lean 100% into CONNECT as the standard datapath for tunneling if we expect substrate to be controlled by a higher-order system. I only want to bite off one controversial issue at a time, so I'll save that for later 😄

Breaking change

Clients that previously selected an Actor with Host: <actor>.<atespace>.actors.resources.substrate.ate.dev must now send both X-Ate-Actor-Name: <actor> and X-Ate-Atespace: <atespace>. The custom Actor DNS suffix is removed. Host/:authority remains application metadata, except that CONNECT authority still carries the target port.

• Tests pass
• Appropriate changes to documentation are included in the PR

[Eitan Yarmush (EItanya)]

Looking good to me overall. Just a few nits. Also I think we need to figure out how to message this to the community as it will definitely break existing demos and things.