cephfs revoke caps逻辑

1. 用户请求路径上需要争夺caps时需要当前caps持有者release（如client1请求mkdir -p /test/a，需要确保其它client的a的以上父目录的caps释放）

• server侧 经过Server::handle_client_request -> Locker::process_request_cap_release -> Locker::eval() -> Locker::issue_caps() -> MDSRank::send_message_client_counted()发送op=CEPH_CAP_OP_REVOKE的消息给相应的client，然后handle_client_mkdir() -> rdlock_path_xlock_dentry() -> path_traverse() -> acquire_locks() -> Locker::wrlock_start()，直到lock变成stable，然后再执行（如果没有stable，跳出循环，加入重试队列），另一方面，server收到CEPH_CAP_OP_UPDATE操作（CEPH_MSG_CLIENT_CAPS消息）后，经过Locker::handle_client_caps() -> eval() -> eval_gather()（由于filelock的state为LOCK_SYNC_LOCK,不是稳态，所以去eval_gather, state状态的转换过程是LOCK_SYNC_LOCK --> LOCK_LOCK --> LOCK_LOCK_SYNC --> LOCK_SYNC，在mkdir的acquire_lock过程中，将LOCK_SYNC转换成LOCK_LOCK_SYNC，这里再将状态转换回来，转换成LOCK_SYNC）,接下来在finish_contexts中执行finishers中的回调函数，finishers存了之前的C_MDS_RetryRequest。即重新执行handle_client_mkdir

• client侧经过Client::ms_dispatch2() -> Client::handle_caps() -> Client::handle_cap_grant() -> check_caps() -> send_cap() 发送CEPH_CAP_OP_UPDATE操作（CEPH_MSG_CLIENT_CAPS消息）给server