Tighten validity checks

Regression from fix for ITS#7403

This needs to be confirmed:
Location based atomics do not imply a full fence of the same level. So
to get the code in dispose() read the actual data, it seems we need to
initiate a fence.

It is used internally to identify pinned operations and should not be
encountered over the wire.

If we're idle, there might be objects pending cleanup for the last two
epochs. Unless another thread comes in and checks into a new epoch or we
shut down, they will linger forever.

If one of the objects was a connection, it wouldn't get closed and be
stuck in CLOSE_WAIT state, potentially refusing another ligitimate
connection if its socket address were to match the one we're yet to
close.

Reject operations in such a case with LDAP_BUSY. If read_event feature
is on, just stop reading from the connection. However this could still
result in deadlocks in reasonable situations. Need to figure out better
ways to make it safe and still protect ourselves.

Switched off unless thread debugging is on, but still useful for static
analysis.

A full read cycle can take a very long time if the limits are set too
high.

Similar to the algorithm presented in
https://www.cl.cam.ac.uk/techreports/UCAM-CL-TR-579.pdf

Not completely lock-free at the moment. Also the problems with epoch
based memory reclamation are still present - a thread actively observing
an epoch getting stuck will prevent LloadConnections and LloadOperations
being freed, potentially running out of memory.

LDAP_UNAVAILABLE signals "the server is shutting down or a subsystem
necessary to complete the operation is offline", so intelligent clients
tend to infer the connection will not be usable any more, which is not
the case here.

Gets rid of a race where unpause+pause fired in a quick succession would
miss the event_base_loopbreak() call.

Reuse the connection walking facility in timeout management.