Support manually in-place authentication token update

[EAimTY]

As mentioned in #54, the lack of authentication token update mechenism may cause active lease and watch become unusable after the token expire. The solution gave in #45 (comment) does theoretically solved it. However, recreating the client means every LeaseKeeper & Watcher needs to be rebuild. This makes the implementation quite complex.

Since updating token automatically is somehow difficult due to tonic's design (#45), I think updating token manually may be a better solution.

The field token in AuthService is changed to an Arc<Mutex<Option<HeaderValue>>> to support in-place modification and sharing between multiple services. The cost of the Mutex is acceptable since it only involves a clone of a small HeaderValue in every request.

The token update method is temporarily Client::update_auth. I am not sure where to put it since it may not be correspond to any service abstraction.

[EAimTY]

I think there are 3 ways to add the reauthentication API:

1. Add a dedicated struct AuthHandle as a field of Client. It should be able to be got by a method of Client, and be cloned like other fields. We can have methods like update_token and remove_token on it.
2. Add update_token and remove_token to AuthClient. However, this feels weird since XxxClient should only contains certain methods of its rpc service.
3. Keep the current design (and add remove_token) on Client. But since we need &mut Client everytime updating token, this may not be as flexible as the first solution.

IMO the first one is better since it could makes the reauthenticate easier without affecting other running tasks.

[davidli2010]

I think there are 3 ways to add the reauthentication API:

1. Add a dedicated struct `AuthHandle` as a field of `Client`. It should be able to be got by a method of `Client`, and be cloned like other fields. We can have methods like `update_token` and `remove_token` on it.

2. Add `update_token` and `remove_token` to `AuthClient`. However, this feels weird since `XxxClient` should only contains certain methods of its rpc service.

3. Keep the current design (and add `remove_token`) on `Client`. But since we need `&mut Client` everytime updating token, this may not be as flexible as the first solution.

IMO the first one is better since it could makes the reauthenticate easier without affecting other running tasks.

I preferred the second. Add to AuthClient:

etcd_client::auth_client().update_token(name, password);

[EAimTY]

I preferred the second. Add to AuthClient:

etcd_client::auth_client().update_token(name, password);

The methods in AuthClient correspond one-to-one with the service Auth in protobuf, and all functions involve changes to the cluster configuration.

Therefore, I prefer the first approach, where the method for updating the client token is placed in a separate handler. This ensures the correspondence between XxxClient and the corresponding RPC service

[davidli2010]

The methods in AuthClient correspond one-to-one with the service Auth in protobuf, and all functions involve changes to the cluster configuration.

There are no strict restrictions that require AuthClient and rpc to have a one-to-one correspondence, AuthClient is responsible for functions related to authentication, and it feels a little strange to have both AuthClient and AuthHandle.

[EAimTY]

AuthClient is responsible for functions related to authentication

A more accurate description, in my opinion, would be that AuthClient is responsible for modifying and querying authentication information of the cluster. As for the token setting on the client side, I don't think it's appropriate to include them here

[davidli2010]

AuthClient is responsible for functions related to authentication

A more accurate description, in my opinion, would be that AuthClient is responsible for modifying and querying authentication information of the cluster.

I don't think it's necessary to take the AuthClient's responsibilities too seriously. I don't want to restrict AuthClient to server-side settings and create separate objects for both client-side and server-side.

[EAimTY]

I have no idea why clippy fails 😅

[davidli2010]

I have no idea why clippy fails 😅

Fixed in #80