Stopgap solution to ID token for outbound requests

[c0c0n3]

This PR implements a stopgap solution to adding DAPS ID token headers to requests originating from Orion and directed to a remote IDS connector outside the mesh.

Functionality overview

When Orion sends an HTTP request to a remote IDS connector (typically to notify of entity updates), a DAPS ID token needs to be added to the outgoing request so that the remote connector can identify the sender. This PR implements exactly that. We get the token from a configured DAPS service through mTLS, insert it in an IDS JSON "result message", Base64-encode the JSON, and add a header to the request. The header's name is header and its value is the Base64 block.

Does it ring a bell? Well, that's pretty much what we did already for Orion HTTP responses to requests from a remote client (a.k.a. consumer) connector. In fact, we're supposed to add the IDS ID header identifying Orion to both responses to consumer connectors (PR #16) and requests to server (a.k.a. provider) connectors, which is what this PR does.

Implementation overview

Having the ID token implementation for responses (PR #16), you'd think we should've been able to just reuse it as is and plonk the ID token in Orion requests by dint of Istio config. While that was the plan, it didn't pan out---see #24. As a workaround, this PR implements:

• an adapter HTTP endpoint where you can get a Base64-encoded IDS JSON "result message" with an Orion DAPS ID token in it; and
• an Envoy filter to intercept Orion requests, get the Base64 block from the adapter HTTP endpoint and add the IDS header to the request.

The HTTP endpoint reuses PR #16's GenerateToken function to get an ID token from DAPS and produce the output Base64 block. Notice though that to do that, the HTTP endpoint has to be able to get hold of Istio adapter config data. Where does it get it from? Well, the Mixer always calls the adapter's gRPC endpoint with the current config, so on getting that data, the adapter caches it in memory so that it'll be available to any subsequent call to the HTTP endpoint.

Shortcomings

1. The adapter is stateful (config data cache) even though it runs on K8s pretending to be a stateless workload, so e.g. it can't be replicated.
2. The HTTP endpoint won't be able to get a DAPS token until such a time the Mixer hits the adapter gRPC endpoint for the first time---the Mixer calls the adapter whenever an HTTP request for Orion comes into the mesh.
3. Because of (2), whenever the operator reconfigures the adapter (e.g. kubeclt apply -f new-istio-cfg.yaml), they should also make a dummy call to Orion straight afterwards (e.g. GET /v2) so that the Mixer calls the adapter with the new config. Otherwise later calls to the HTTP endpoint may fail due to a stale cache.
4. Ditto for image deployments and pod restarts. Restarts are a problem since in general you won't know when K8s will do that or for that matter when the pod gets relocated to another node.
5. Security needs tightening. The HTTP endpoint blindly returns the token, no questions asked. While the endpoint isn't exposed outside the mesh, this isn't obviously optimal.
6. Fragile Lua script---see Envoy filter.

See #24 for what to do about these sore points.