msgr: drop messages on cons with CLOSED Pipes

Back in commit 6339c5d43974f4b495f15d199e01a141e74235f5, we tried to make
this deal with a race between a faulting pipe and new messages being
queued.  The sequence is

- fault starts on pipe
- fault drops pipe_lock to unregister the pipe
- user (objecter) queues new message on the con
- submit_message reopens a Pipe (due to this bug)
- the message managed to make it out over the wire
- fault finishes faulting, calls ms_reset
- user (objecter) closes the con
- user (objecter) resends everything

It appears as though the previous patch *meant* to drop *m on the floor in
this case, which is what this patch does.  And that fixes the crash I am
hitting; see #4271.

Signed-off-by: Sage Weil <sage@inktank.com>
Reviewed-by: Greg Farnum <greg@inktank.com>
osd: show retry attempt in MOSDOp operator<<

Signed-off-by: Sage Weil <sage@inktank.com>
osd: include osdmap epoch in osd_op message operator<<

Signed-off-by: Sage Weil <sage@inktank.com>
osd: useful debugging for when we drop requests

Signed-off-by: Sage Weil <sage@inktank.com>
osd: add 'osd debug op order' to track and assert order of client ops

Keep a big fat slow map in memory to ensure that client ops are applied to
objects in the order the clien sent them.  This will make it easier to
catch ordering bugs due to requeuing as soon as they happen, when the logs
are easier to wade through, and not later when the client notices something
is awry.

Signed-off-by: Sage Weil <sage@inktank.com>