DNM: osd: handle racing mark_down and msg delivery

The run failed because the first message marked the source down (old, down
osd) while the second message was in the delayed delivery queue.  When it did
arrive we hit teh assert(session).

The delayed queue is simple enough to fix, but the mark_down +
con->set_priv(NULL) sequence in require_same_or_newer_peer() can be called
from both fast dispatch and regular dispatch contexts, which (I think) means
that we need to always be prepared to deal with there being no session and
thus dropping the message on the floor.

I'm unsure about the third patch where there is some counting going on of
osdmaps we are expecting in on teh socket.. we could see the epoch in the
ms_fast_preprocess() call but then have the session gone by the time it
reaches ms_fast_dispatch().  Will that break anything?
Okay, this is just stopping us from doing anything with watch-notify, right?