Non-stub setvbuf

[Rich Felker <dalias@libc.org>]

Right now, musl's stdio setvbuf function does nothing but set the
buffering mode; it does not honor the buffer provided by the caller.
This is perfectly conforming (whether or how the buffer is used is
unspecified), but I realized from the recent thread about OpenSSH's
CVE-2016-0777 on oss-security that a non-stub setvbuf admits a nice
type of hardening:

http://www.openwall.com/lists/oss-security/2016/01/15/15

In short, the application has no way to scrub implementation-internal
stdio buffers that might contain sensitive data read from or written
to files, but it can scrub buffers it provides via setvbuf. So, I'd
like to start actually using the latter, so that apps that attempt
this hardening measure can benefit from it on musl like they would on
other implementations.

The logic I have in mind is something like:

- Ignore application-provided buffers smaller than UNGET (8) bytes,
  possibly plus some reasonable epsilon, and either turn off buffering
  or keep the internal buffer in this case.

- If the application-provided buffer is larger than something
  threshold M (maybe 16k) and the file mode admits reading, only use
  the first M bytes of the buffer. Otherwise repeated fseek+getc is
  very slow (uselessly refilling a large buffer each time).
  Alternatively the logic to limit read buffer size could go in
  __stdio_read.

Does this sound reasonable?

I also reviewed the lack of locking in setvbuf, which looks like it
risks data races accessing f->flags, but it actually seems fine since
the only code that could run concurrently with it without invoking UB
is __stdio_exit (or perhaps fflush(NULL)) which just checks f->rpos,
f->wpos, etc. Perhaps some comments should be added to this effect,
though.

Rich