For short writev results, update bufq rpos correctly

We were moving rpos to the end unconditionally.  Is situations where
the data is large and a short writev result is encountered, we'd believe
that we had sent all the data that was there when we actually had not.

Manifestations would be missing chunks of data in the worst case, or
stalled sessions in the best case (due to protocol mismatch)
Downgrade ssl errors to INFO level

A surprising number of SSL/TLS enabled services on the public internet
have broken configurations (ranging from invalid certs, to "bad" cipher
selections).

Avoid making noise in the log stream when these are encountered.

We probably should have a way to tap into the underlying SSL error stack
in case there are interesting things that could be done at a high layer
in the stack, but for most practical purposes all we care about is that
an error was found.
Be more aggressive at applying nbio masks

If we are the target emitter, there is no reason to defer applying
timer or epoll settings because we won't see the results of these
changes until we unwind back up the stack; the purpose of deferring
changes is so that the target nbio or thread pool won't start until
after the current dispatch has unwound enough such that we avoid
bugs where the target thread completes before the originating thread
has finished revising its state to receive completion notification.