cmd-t now spawns in the same domain as the active tab,
cmd-shift-t spawns in the default domain.
It is possible to define bindings to spawn in an arbitrary domain.
In the early days we relied upon the bounded length of a sync channel
to put back pressure on the output from a child command. We're no
longer using that kind of channel, so here's a more deliberate and
measurable rate limiting implementation.
The `ratelimit_output_bytes_per_second` configuration setting defaults
to 2MB/s and constrains the amount of text we send to the escape
sequence parser.
This value was selected based on it being a combination of responsive
to ctrl-c while outputing a lot of data and still generating sleeps
to remain within the constraints.
This does mean that terminal benchmarks that test how quickly you
can dump text to the terminal will hit this artifical upper limit
and are thus not going to be a true measure of performance.
This removes some redundancy and overhead around setting up the
connection (the native_tls crate doesn't provide PEM functions,
despite every deployment I've ever seen only ever using PEM certs),
but more importantly, gives the control needed to make hostname
verification work in a PKI setup with unusual CN values.
Problem scenario was:
* spawn a window
* resize it larger
* spawn a new tab
When working with a mux client tab, the surface size in the new tab
didn't reflect the size of the remote surface, so the rendering was
messed up.
Arrange to know the size up front.
Repeated moves or wheel events are collapsed so that we don't clog up
the queue. The queue size doesn't matter as much as the latency of
processing a large queue. For fast or repeated moves the queue can grow
rather quickly, and with what is currently ~25-50 ms round trip per
entry for a remote session, that is a poor UX.
The latency is not great, and there are more authentication and
authorization features that need to be added, but this shows that
we can connect and talk to a remote muxer.
