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.
