mds: do not defer incoming mgrmap when mds is laggy

mds: do not defer incoming mgrmap when mds is laggy

When the mds is laggy, the incoming mgrmap is queued to be processed
at a later stage. But, the mds does not handle mgrmap message directly.
So, later when the mds is not laggy anymore, the mgrmap message is not
handled and is dropped. But, when the mgrmap message was queued up, the
mds acknowledges that it has handled the message. This causes the mgr
client instance to never process the mgrmap and never connecting to the
manager (the receipt of mgrmap drives the connection to the manager).

The fix is to not acknowledge messages that the mds cannot handle. In
normal cases, the mds does not ack the message but when it's laggy, it
just blindly queues up the message -- so, check if the message can be
handled (later) even when the mds is laggy.

Also, a minor change in a function name -- handle_deferrable_message()
is kind of a misnomer since the function is called to process messages
that are not deferred. That's changed to handle_message() now.

Fixes: http://tracker.ceph.com/issues/44638
Signed-off-by: Venky Shankar <vshankar@redhat.com>
(cherry picked from commit beb12fa25315153e1a06a0104883de89776438a6)