As SSE are unidirectional, the client always realises that the
connection has failed faster than the server does. Hence, resuming a
subscription is useless, because channels can only be bound to one duct
at a time. Now, instead of failing a request for a channel
that is already bound to a duct, we replace the duct and continue
normally.
Avoid allocating hundreds of thousands of cells when giving large
requests. This took the footprint of this function on initial landscape
load from 1 second to 100 ms.
* jb/motion:
pill: solid
zuse: remove %crud from vane-task
arvo: full vane names in $sign
aqua: build again (still broken)
arvo: reform of the scry reform
Eyre's clog logic was a tad inconsistent about "only facts" vs "not poke-acks".
This makes it consistently say "only facts" when it comes to clog-related logic.
Yes, in theory this means %watch-acks and %kicks can build up endlessly, but
those should take up negligible space compared to %facts.
Should fix any oddball cases of crashes here that #3835 didn't already catch.
Pretty-printing is expensive, yet we do it whenever we construct the cookie
string, at least once (but usually twice) per authenticated request.
Here we call out the the specific to-tape functions we need, instead of relying
on the pretty-printer for converting... tapes to tapes, among other things.
The primary gains come from the cookie-related instances, we update the others
mostly for good style.
For the "receive request and immediately send response" case, that is processed
synchronously within eyre (ie, client sends channel ack), speeds thing up by
roughly 55%.
If the Forwarded header specifies the original connection is secure,
update the flag to reflect that, regardless of whether the connection
directly to the urbit was made securely.
When an application would send multiple facts during a single event, it
was possible for the first fact to trigger a clog, removing the
subscription and sending a quit, but then the second fact still getting
sent out at normal.
Here, we drop any facts for subscriptions we don't have registered in
state, which should only happen in the described case.
Because storing in reverse order means producing in reverse reverse
order.
The tests didn't catch this because they, too, were infected with the
"reverse moves" meme.
