mds: remove MDCache::rejoin_fetch_dirfrags()

In commit 77946dcdae (mds: fetch missing inodes from disk), I introduced
MDCache::rejoin_fetch_dirfrags(). But it basicly duplicates the function
of MDCache::open_undef_dirfrags(), so just remove rejoin_fetch_dirfrags()
and make open_undef_dirfrags() also handle undefined inodes.

Signed-off-by: Yan, Zheng <zheng.z.yan@intel.com>
mds: include replica nonce in MMDSCacheRejoin::inode_strong

So the recovering MDS can properly handle cache expire messages.
Also increase replica nonce when sending the cache rejoin acks.

Signed-off-by: Yan, Zheng <zheng.z.yan@intel.com>
mds: encode dirfrag base in cache rejoin ack

Cache rejoin ack message already encodes inode base, make it also encode
dirfrag base. This allowes the message to push stray dentries to other MDS.
The function will be used by later patch.

Signed-off-by: Yan, Zheng <zheng.z.yan@intel.com>
mds: handle linkage mismatch during cache rejoin

Signed-off-by: Yan, Zheng <zheng.z.yan@intel.com>
mds: reqid for rejoinning authpin/wrlock need to be list

Signed-off-by: Yan, Zheng <zheng.z.yan@intel.com>
mds: also take object's versionlock when rejoinning xlock

Signed-off-by: Yan, Zheng <zheng.z.yan@intel.com>
mds: share inode max size after MDS recovers

The MDS may crash after journaling the new max size, but before sending
the new max size to the client. When the MDS recovers, the client
re-requests the new max size, but the MDS finds max size unchanged. So
the client waits for the new max size forever. The MDS can avoid this
potential issue by checking client cap's last_sent, share inode max size
if it is zero. (reconnected cap's last_sent is zero)

Signed-off-by: Yan, Zheng <zheng.z.yan@intel.com>
mds: issue caps when lock state in replica become SYNC

because client may request read cap from non-auth MDS.

Signed-off-by: Yan, Zheng <zheng.z.yan@intel.com>
mds: send lock action message when auth MDS is in proper state.

For rejoining object, don't send lock ACK message because lock states
are still uncertain. The lock ACK may confuse object's auth MDS and
trigger assertion.

If object's auth MDS is not active, just skip sending NUDGE, REQRDLOCK
and REQSCATTER messages. MDCache::handle_mds_recovery() will handle
them.

Signed-off-by: Yan, Zheng <zheng.z.yan@intel.com>
mds: add dirty imported dirfrag to LogSegment

Signed-off-by: Yan, Zheng <zheng.z.yan@intel.com>
mds: avoid double auth pin for file recovery

Signed-off-by: Yan, Zheng <zheng.z.yan@intel.com>
mds: check MDS peer's state through mdsmap

Signed-off-by: Yan, Zheng <zheng.z.yan@intel.com>
mds: unfreeze subtree if import aborts in IMPORT_PREPPED state

Signed-off-by: Yan, Zheng <zheng.z.yan@intel.com>
mds: fix export cancel notification

The comment says that if the importer is dead, bystanders thinks the
exporter is the only auth, as per mdcache->handle_mds_failure(). But
there is no such code in MDCache::handle_mds_failure().

Signed-off-by: Yan, Zheng <zheng.z.yan@intel.com>
mds: notify bystanders if export aborts

So bystanders know the subtree is single auth earlier.

Signed-off-by: Yan, Zheng <zheng.z.yan@intel.com>
mds: don't open dirfrag while subtree is frozen

Signed-off-by: Yan, Zheng <zheng.z.yan@intel.com>
mds: clear dirty inode rstat if import fails

Signed-off-by: Yan, Zheng <zheng.z.yan@intel.com>
mds: clear EXPORTBOUND before try merging subtree

Signed-off-by: Yan, Zheng <zheng.z.yan@intel.com>
mds: don't replicate purging dentry

open_remote_ino is racy, it's possible someone deletes the inode's
last linkage while the MDS is discovering the inode.

Signed-off-by: Yan, Zheng <zheng.z.yan@intel.com>