This enables using large OSC buffers in a form that we can publish
to crates.io without blocking on an external crate. Large OSC
buffers are important both for some tunnelling use cases and for
eg: iTerm2 image protocol handling.
This adds some plumbing so that a domain can indicate whether it is
attached or not, but is not yet smart enough to detect a closed
connection and mark itself as detached.
Add a convenience function to the escape parser that, like `parse_first`,
matches only the first escape sequence, but instead collects all matching
actions.
The sync_channel was originally added as a brake to avoid swamping
the event loop, but we've subsequently grown a more formal rate
limiting config for this.
The rate limiter is superior because it allows making forward
progress over time, whereas the bounded channel is a hard blocking
limit.
When making a large paste the app on the other end will typically
emit a lot of output. If our reader is blocked on the sync channel
the output of the pty can be blocked, and that in turn will block
our attempt to write to the pty.
We cannot simply set the pty to non-blocking mode because non-blocking
ptys are not a thing on windows, and in the interest of not silently
breaking windows, I prefer to make the unix side of things match
that architecture.
anyway: TL;DR is that we don't need the bounded channel now that
we have rate control to manage swamping the event loop, so we
can simplify this code.
I'm committing this because it captures a repro for the situation
described across these two issues:
Refs: https://github.com/jekyll/jekyll-archives/issues/28
Refs: https://github.com/jekyll/jekyll/issues/6209
This commit has a workaround in place; to demonstrate the problem,
change this line of `_layouts/default.html`:
```
{% include toc.html sanitize=true baseurl=p.url html=p_content %}
```
to:
```
{% include toc.html sanitize=true baseurl=p.url html=p.content %}
```
Then navigate to various pages: the TOC in the LHS inconsistently
shows headers from different pages depending on the current page.
It takes ~30 minutes to schedule a release build that takes just
over 50 minutes to run. Travis kills builds that take 50 minutes,
so this is completely useless.
Meanwhile: azure is able to build and deploy all platforms within
the first 15-20 minutes.
