Fix buffer overflow in scrap and scuttle

Remote hole, can smash the stack.  Additionally, the confirmation
prompt is misleading when the player supplies conditionals.  Redesign
the flawed prompt.

Broken when Chainsaw added the confirmation prompt.  Reported by Scott
C. Zielinski.
Fix buffer overflow in build

Remote hole, can smash the stack.  Broken when Empire 2 added the
confirmation prompt.
Clean up io_input() for the "no input available" case

Return zero when no input is available, regardless of parameter
waitforinput.  Before, it returned -1 with errno set to EAGAIN or
EWOULDBLOCK when not waiting for input.  Current callers all wait.

Drop errno from the function's contract, for consistency with
io_output().
Replace the per-iop input_timeout by per-function timeouts

Commit 08b94556 (v4.3.20) added io_open() parameter input_timeout.  It
applies to io_input() and, since commit 904822e3, to io_close().  Add
timeout parameters to these functions instead.
Base idle timeout on player->curup again, not current time

Idle timeout used to expire max_idle minutes after the last
player->curup update.  When we got rid of the idle thread in commit
08b94556 (v4.3.20), this got changed to "wait no more than max_idle
minutes for input".  Time spent computing and time spent blocked on
output no longer counts.  In particular, a connection can block
indefinitely on output since then.  Let's fix that.

Start with basing the input timeout on player->curup again.  The
missing output timeout will be added shortly.

Aside: since status() updates player->curup, the idle timer gets reset
when the update aborts a command.  Left for another day.
Unbreak nightly build

The nightly build uses a gross hack to keep timestamps stable: it
replaces the system's time() by emp_time().  It doesn't replace other
time-related functions such as gettimeofday().  Works as long as we
don't mix hacked time with unhacked time.

The previous commit compares time gotten from gettimeofday() with time
gotten from time().  The nightly build's I/O timeouts become zero,
which makes login impossible.

Replace gettimeofday(), too.
Switch io_close(), io_input() from timeouts to deadlines

All users want deadlines.  Move the conversion from deadline to
timeout from callers to io.c, where it becoems an implementation
detail.
Add deadline support to io_output(), io_output_if_queue_long()

Replace parameter wait by deadline.  Non-zero wait argument becomes
(time_t)-1 argument, zero wait argument becomes zero deadline
argument.  No functional change, yet.
Fix io_close() to obey deadline for output, too

A client can delay thread exit indefinitely by not reading output.
Broken in commit 08b94556 (v4.3.20) "Reimplement max_idle without a
separate thread".  Until then, the idle thread aborted a stuck attempt
to flush output.

Denial of service seems possible.

Note that commit 904822e3 moved flushing the output queue from
player_login() to io_close().  It also made io_close() wait for the
client to close the connection.  That wait obeys the deadline.
Flush all output before reading a login command, not just some

Before, a client could theoretically make the output queue grow
without bounds.
Fix player_login() to obey max_idle for output, too

player_login() flushes the output queue before receiving input.  The
receive obeys max_idle, the flush doesn't.  Which means a client could
hog the thread indefinitely.

Broken in commit 08b94556 (v4.3.20) "Reimplement max_idle without a
separate thread".  Until then, the idle thread aborted a stuck attempt
to flush output.

Denial of service seems possible.
Clean up how recvclient() deals with command abortion

We must not block in io_input() after command abortion unblocked
io_output().  Instead of checking player->aborted, compute the
deadline according to player->may_sleep, like we do for io_output().
Fix recvclient() to obey max_idle for output, too

recvclient() flushes the output queue before receiving input.  The
receive obeys max_idle, the flush doesn't.

Broken in commit 08b94556 (v4.3.20) "Reimplement max_idle without a
separate thread".  Until then, the idle thread aborted a stuck attempt
to flush output.
Factor player_output_some() out of pr_player(), upr_player()
Fix pr_player() and upr_player() to obey max_idle

The output queue flush can block indefinitely.  Permits a client to
hog the thread indefinitely by not reading output.

Broken in commit 08b94556 (v4.3.20) "Reimplement max_idle without a
separate thread".  Until then, the idle thread aborted a stuck attempt
to flush output.

Denial of service seems possible.
Fix unwanted player thread blocking on output during shutdown

shutdwn() disables blocking on I/O for all player threads in state
PS_PLAYING, by setting struct player member may_sleep to
PLAYER_SLEEP_NEVER.  This ensures the player threads complete logout
quickly and reliably.  A thread may still block on I/O in io_close()
called from player_delete(), since commit 904822e3, but that's okay,
because it happens after all game state updates.

Bug: if shutdwn() aborts a command, the player thread returns through
dispatch(), which resets may_sleep back to PLAYER_SLEEP_FREELY.  Input
can't block regardless, because the EOF indicator is set, but output
can.  When it happens, the player thread may not complete logout
before shutdwn() terminates the process.

This can make us lose a treasury update (similar to the bug fixed by
commit bdc1c40f; the relevant bug description is in commit note
6f8ca87f), play time update, and log entries.

How?  There are two paths from dispatch() to player_delete().  Here's
the first one:

  1. command()
     Doesn't print since dispatch() returns 0 when it resets may_sleep
  2. player_main()
     Loop and call status()
  3. status()
     If the command set dolcost to a non-trivial amount, print it
     Charge dolcost
     If player went broke or became solvent, notify him
     Charge time used
     Return 0, because shutdwn() set the EOF indicator
  4. player_main()
     Break the loop
     Charge time used
     print Bye-bye
     journal.log the logout
  5. play_cmd()
     server.log the logout
  6. player_login()
     Loop
     Try to flush output
     get EOF, break loop
     print so long
     call player_delete()

Ways the bug can bite:

A. When we block in 4. print Bye-bye, we can fail to log.

B. When we block in 3. print broke/solvent notification, we can
   additionally fail to charge time used.

C. When we block in 3. print dolcost, we can additionally fail to
   charge dolcost.

Note: B. and C. couldn't happen before commit bdc1c40f.  Instead,
something just like C happened always, whether player thread blocked
or not.

The second path:

  1. execute()
     Loop and call status()
  2. status()
     As above
  3. execute()
     break the loop
  4. dispatch()
     Continue with the first path

No additional ways to bite.

Fix by avoiding the may_sleep reset when the player thread is on its
way to terminate: may not sleep and has its EOF indicator set.

Broken in commit 0a4d77e9, v4.3.23.
Separate login_grace_time from max_idle

max_idle applies in state PS_PLAYING, login_grace_time before (login,
state PS_INIT) and after (logout, state PS_SHUTDOWN).

Cut login_grace_time to two minutes, from max_idle's 15.  Two minutes
is plenty to complete login and logout.  Makes swamping the server
with connections slightly harder, as they get dropped faster.  While
that makes sense all by itself, the real aim is making increasing
max_idle safe.  The next commit will complete that job.
Separate max_idle_visitor from max_idle

Cut it to 5 minutes, from max_idle's 15.

Since max_idle now applies only to authenticated players, increasing
it is perfectly safe.
Change login command kill to kill less ruthlessly

The victim's connection closes without any explanation.  Output may be
lost.  This is because kill_cmd() kills by calling io_shutdown(),
which shuts down the socket and drains the I/O queues.

How this makes the victim's thread terminate is a bit subtle: shutting
down the socket makes it ready.  If the victim's thread is waiting for
I/O, it wakes up.  Since all further reads return EOF, and all further
writes fail, the command terminates quickly (short of inifinite loop
bugs), then the command loop, and finally the thread.

To make kill behave more nicely, change kill_cmd() to work exactly
like server shutdown: send a flash message to the victim, set his EOF
indicator, abort the command, forbid sleeping on I/O, wake up the
victim's thread.  Just as reliable, but doesn't lose output.

If the victim's client fails to close his connection, the victim's
thread may still linger in state PS_SHUTDOWN for up to
login_grace_time (default 120s).  An attacker could try to use that to
make the server run out of file descriptors or memory, but simply
connecting achieves the same effect more cheaply.
io_shutdown() is now unused, remove