Replace the pipe we used to communicate errors after fork(), but
before exec() to the parent process with an event FD.
The overhead in the kernel is much lower to setup an event fd,
compared to a pipe.
Since we need to restore the status flags anyway, there's nothing to
gain from emitting the user notifications after dup:ing the pts file
descriptor.
On the other hand, emitting user notifications *before* dup:ing means
we can still print error messages for e.g. write(3) errors.
We (need to) set O_NONBLOCK on the pts file description before
emitting the user-notifications, to ensure we don't block in write(3).
However, since file status flags are per *file*, not per
file *descriptor*, this ends up setting O_NONBLOCK on the dup:ed
stdin/stdout/stderr file descriptors too.
Not all clients want this, or can handle this.
Thus we need to restore the original flags before exec:ing the client.
This fixes "makepkg" build failures.
The main process is blocking and waiting for us to close the error
pipe (in exec(3), via O_CLOEXEC).
Thus, pts data will *not* be processed until we've exec:d the shell.
Because of this we must not write too much and block in write(3). Do
this by setting O_NONBLOCK on the pts fd (*after* dup:ing it to
stdin/stderr/sdout) and watch for EAGAIN EWOULDBLOCK.
* Rename user_warning to user_notification
* Add warning and error types (in addition to the existing deprecated)
* Simplify logic when emitting a user notification after forking; we
don't need to copy the notification data since we're in a new
process and have total control over that memory.
This is used when spawning the slave, to set its current working
directory just before we exec() the client.
In a regular foot instance, we set the cwd from getcwd().
In a foot server instance, each connecting client sends its cwd to the
server, and we use that.
