This completely drops libuv as a dependency and uses [libxev](https://github.com/mitchellh/libxev) instead.
The _primary_ reason to do this is easier building, cross-compiling, and the ability to write a WASM backend in the future. However, we don't want to do this unless it has a positive or null impact on performance. On this, we've succeeded!
The performance impact on Linux is very small. The performance impact on macOS is quite large (I'm seeing almost 40% faster on IO heavy workloads). On both platforms, the stddev of IO heavy workloads is much smaller. This isn't libxev itself, this is primarily do to switching to the dedicated read thread (more next).
This PR also has an architectural change: the TTY reads now happen on a dedicated thread _outside the event loop_. I realized that TTY reads are almost always very small and under heavy IO load, the event loop overhead is very heavy. This is particularly true with io_uring since it uses an kernel threadpool under the covers and the context switch cost was very visible. Another factor is that TTY reads are almost always the only thing impacting terminal state. So if we wrap the terminal state in a lock (we already do), there is almost no overhead to moving the reads to a thread since locks aren't slow, lock contention is slow, and we have almost no lock contention under typical loads.
The main impact of the dedicated TTY reader thread is that there is no event loop overhead and the "jitter" between IO reads is now very small.
🚀
When a new tab is added, the tab bar may appear which causes our size
grid size calculation to become invalidated. We weren't updating this
previously, which had the effect of mouse selection being in the wrong
place. There were likely other effects...
Fixes https://github.com/mitchellh/ghostty/issues/69
Saw this on HN:
https://github.com/darrenstarr/VtNetCore/pull/14
I wanted to see if ghostty was vulnerable to it (it is not). But, its a
good example of a weird edge case in the wild and I wanted to make sure
it was redundantly tested. It looks like we read the "spec" (blog posts,
man pages, source of other terminal using tools, etc.) right.
