Flux Adapter preparation

[squaremo]

• makes API changes so that all methods are available over HTTP, including NotifyChange (used for relaying webhooks, for example) /cc @alanjcastonguay
• adds some notes about what can be moved out of this repo and into weaveworks/flux-adapter

This (modulo passing tests and review) can be merged now, in principle, because it doesn't alter what is served over the Upstream connection -- it just adds to the HTTP API. But I am going to make it a draft until I've Actually Tried that.

Fixes #2210.

[ellieayla]

Looks like you missed two api.UpstreamServer references in tests during the great renaming.

remote/mock_test.go:    ServerTestBattery(t, func(mock api.UpstreamServer) api.UpstreamServer { return mock })
remote/rpc/rpc_test.go: wrap := func(mock api.UpstreamServer) api.UpstreamServer {```

[squaremo]

This PR also updates the Upstream connection so it connects to the v11 endpoint. This was introduced as wee while ago to support rollout progress with ListServicesWithOptions, but back-filled in the (versioned) RPC clients so that it would work with older fluxd too.

Usually there's a gap necessary between introducing a new version and rolling out a Flux release that uses it, so that the service part of it can be rolled out in Weave Cloud -- so probably what happened is that, since it worked with the back-filled RPC client, the latter part of the rollout was forgotten.

In any case, I've now Actually Tried It with

• a flux daemon connecting to Weave Cloud (v11 endpoint)
• a flux daemon pointed at the flux adapter, itself connected to Weave Cloud

and both of these work. Specifically, I was looking for all the UI elements to work OK, and for notifications to be propagated to the service.

It should also work fine with justinbarrick/fluxcloud, because that accepts websocket connections at any path.

[hiddeco]

Code changes look solid, and given #2211 (comment) there is enough evidence it works :-)