Wrap up R&D proto

[c0c0n3]

This PR wraps up the R&D prototype, bringing in:

• Configurable request authorisation through AuthZ
• Orion/MongoDB mesh services
• A stable mesh
• More robust mesh configuration and code generation

While there's still quite a bit to do before we can call it a solid product, we have a workable Mixer-based architecture (but see #29) we can use for demos & showcases. In fact, we can

• Intercept HTTP requests targeting any mesh service.
• Validate IDS header payload through configurable RSA infrastructure and deny access or forward requests to the target service according to validation outcome.
• Additionally turn on AuthZ access control so that past token validation, the adapter also asks AuthZ to authorise the request and then denies access or forwards the request to the target service according to AuthZ's decision.
• Do mTLS with a configured DAPS server to get an ID token.
• Inject the ID token in the service response, again using the IDS header mechanism.
• Intercept HTTP requests originating from a mesh service and inject the ID token---this is still not working for Orion (#28) but works for any other service.

Also, our mesh comes by default with

• Orion, MongoDB and httpbin services---httpbin comes in handy for testing.
• Dummy DAPS server---again, useful for testing.
• Ingress/egress routing and telemetry.
• Routing of AuthZ requests to: http://authzforceingress.appstorecontainerns.46.17.108.63.xip.io/authzforce-ce/domains/CYYY_V2IEeqMJKbegCuurA/pdp
• Mesh dashboards---Kiali & Grafana.

So we've got enough leverage to quickly spin up a demo on a box with Minikube or even do it in a K8s cluster for showcases. But here are some limitations to keep in mind:

• ID token for HTTP requests originating from the mesh. This won't work until the first HTTP request hits a mesh service---see #25. Probably not an issue for demos or showcases though since client requests will typically hit the mesh before a mesh service tries to call an external service---e.g. a subscription has to happen before Orion sends out a notification.
• Orion notifications won't have an ID token---see #28, but this feature works for httpbin.
• MongoDB isn't replicated and data is volatile---i.e. no persistent storage.
• HA/heavy loads. You'd need to replicate Orion and do a proper MongoDB cloud install w/ e.g. a Helm chart.
• Latency/throughput. It'd be much better if we had full blown caching in place---see #9.
• Security could be better too---see #15.

[c0c0n3]

@gboege when you can find the time (it'll take a couple of hours probably), it'd be great if you could:

1. check out the dev branch.
2. nuke your local Minikube cluster---yes, really. There are just too many changes since the last time you tested and I've got no migration scripts.
3. follow the instructions in the readme to rebuild your local Minikube cluster and test to make sure what I've done is okay.

In particular, if you could please have a look at how AuthZ calls work since I've made a couple of assumptions that could be totally wrong:

• Resource ID. I stashed it away in a config param (see operator config/authz section) since I thought that was the equivalent of App ID in WILMA---hectic thumb sucking!
• Roles. I saw the example token you gave me had a scopes claim so I thought clients would list in there user roles, similar to OAuth "scope" param.

Changing any of the above is relatively easily though.