The previous code was trying to do too much with local dataflow. This
refactoring splits (stateful) relay upstream subscriptions out into
actors of their own.
Previously, dataflow variables were used to hold a single upstream hub
and a single upstream canonical topic URL. This causes problems when
things change rapidly: an unsubscription or subscription might be in
flight, and there was no way to tell what the resulting state of the
remote topic as a whole should be if the fields had changed between
the start and finish of an in flight action.
The new design follows from the observation that an individual
subscription to an upstream hub is a stateful entity: it deserves
promotion to a full actor. There is now an actor for the remote topic,
and one for each established upstream subscription. Upstream
subscriptions are created in response to demand expressed by the
remote topic actor; to switch, all it needs to do is update its
demand, and new subscriptions will spring into being while surplus
subscriptions gracefully terminate.
Also, this commit fixes a bug where upstream subscriptions were being
made to the requested-topic rather than to the upstream-topic.
Consequently, self-subscriptions (with multiple `http-listener`
aliases) work now without infinite mail loops.
There is still an issue that blocking actions in on-stop clauses don't
run to completion; that is being dealt with separately, as part of a
reexamination of facet-terminating events more generally.
In order to support HTTPS nginx proxying, we need to maintain a
"fictional" baseurl which is not directly connected to this server's
listen ports. This has caused a change to configuration: now, a
baseurl is specified along with one or more listen specifications.
Tony Garnock-Jones