Conservative edge case hunt

I've been hunting down some weird edges this past week.
This commit is a bit of a lump of multiple pieces thrown together;
sorry.

job.c/common.c: Mildly gross check to see if we are pending apply or
pending wakeup in the deferred free routine.  If we are, re-defer and
free later.

memory.c: In tracking down what turned out to be a memory corruption
issue in a client of the library, needed to see which memtypes were
at fault in some of our abort cases, so introduce memory_panic as a
means for showing them.  The memtype paramter is typically optimized
aware making it impossible to debug sanely via coredump.  We can't
simply use ph_panic() in here as this may need to allocate memory
and cause a double fault.

epoll.c: don't inspect kmask as a means to avoid epoll_ctl syscalls.
Relax the panic condition.  In the hunt this past week, it looked
like were not applying our changes to epoll in a timely fashion.
This change raises the volume of epoll_ctl syscalls that we make as
a conservative measure to ensure that the correct state is applied.
It may be that we don't need to be so aggressive, but for now, we
know that this results in correct operation.

socket.c: be more aggressive at pumping data into the appropriate bufqs.
We saw what looked like stalled sessions (perhaps due to the reasons
mentioned above for epoll.c) so we wanted to ratchet things up a bit.
Also: when suspended, don't try to operate on bufqs when we get
signalled.

ssl_stream.c: if someone tries to use us after we've been closed,
indicate an EBADF error rather than segv.
Fixup some lint checks

These weren't visible on my other system
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.
fixup osx and solaris builds to match epoll changes

Moral equivalent of the epoll.c changes in
37f54141e7739f8825c751708fd04f5974fb53ed

Without this, iobasic.t will fail on OSX.  Solaris doesn't seem to care,
but we should make the equivalent change for consistency.
prevent invalid free when using string slices

I think I must have thought that the INVALID value was -1... :-/

Without this fix, the revised unit test will fault
add assertion to catch a double ph_job_free()
avoid fault when printf'ing a null ph_string_t
extend epoch around the full set of events from epoll

The observation was that a mixture of timer and fd events coming back in
a batch would operate on the same job; one would cause the underlying
data to be ph_job_free()'d and reaped by the time the second one was
dispatched.

The equivalent to this should also be applied to the other nbio
implementations.

Also: fix missing mask assignment in the removal case.
sock: fixup stuck SSL sessions, tidy up free and affinity

* For async connects, round-robin over the emitters for the completion
  callback for better distribution.  You may use the new
  ph_thread_emitter_affinity() function to obtain an affinity value
  for the currently executing thread.  This is useful in cases where
  you create a job for a connected socket and want to maintain
  affinity with the connection callback thread (this is usually
  desirable in order to minimize the chance that you schedule the
  same fd in two different epoll instances on different threads)

* For longer lived SSL sessions and/or systems under load with a
  large number of concrrent SSL sessions, we observed that we could
  get stuck pending read with partial data in the read buffer.
  The data was actually read and staged somewhere in the SSL internals.
  Avoid getting stuck by performing a speculative read after a dispatch;
  if the read buffer size changed then we make another pass through
  the dispatch callback.  This looks fugly and can bias towards
  hot sessions, but works well in practice thus far.