=============================================
Most of the tests are testing the authentication.

Scenario 1:
serverA creates context with user and calls serverB calls server C
for example, h2gproxy
create context with "user/password" and "token" and "OTP/challenge/pin"

Scenario 2:
cmdline calls serverA calls serverB calls server C
for example, some cmdline tool

Scenario 3:
serverA creates context with no user and calls serverB calls server C
for example, a 'database backup service'

Scenario 4:
serverA creates context with user and calls server B. serverB stores request and executes new request some time (e.g. days) later with a context with that user
for example, a 'trigger me if something happens" service

The scenarios contain shared code, which is in shared

=============================================
Considerations:

* Performance is quite important. We expect a goeasyops-server to run locally next to the caller, but all clusters share common userids etc.

* Simple for developers. The go-easyops framework must, at most, depend on a single service which also provides a local mode, possibly with 'mock'. This
means it must "proxy" services, such as auth-, registry-

* A local service must be accessible by upstream services. (register with an upstream registry)

* A local service must prefer local services. (use a different, local registry instead of upstream)


=============================================
Context is for passing API Boundaries. It may not be familiar to developers looking at this code to understand why the context is used so often, but it is its intented and useful purpose.

=============================================
In order to pass, each test must
a) cleanly pass auth information through to next service, including a requestid
b) must reject calls if a signature does not match


==============================================
Design Idea:
* expose a service which returns a registry address
* Service expected to be _always_ available on localhost:5000
* split behaviour into "DC mode" and "Dev mode"
--- dc mode:
1) return the 'cluster' registry
--- dev mode:
1) return localhost:5000 for registry, auth-service (and any other required services)
2) expose grpc mock services on localhost:5000 for these services

further Features:
* expose all (authorised) services (including hosted in datacenters) on localhost:5000 and proxy those
* expose all local services to a datacenter proxy of sort (tbd)