feat: add the WatchState API

[Rustin170506]

close #551
close #567

This pull request introduces a new stream API named "WatchState." Currently, it only provides the current temporality, which will enable clients to check if the server has been paused.

See more: #567 (comment)

[Rustin170506]

@hds Do you have time to take a quick look at this pull request before I continue? I want to ensure I'm on the right track and understand your feedback correctly.

Do you have any thoughts on how to use it with tokio-console? Currently, we use next_update to connect to the server and handle all the backoff stuff. I'm not sure how to use this new API in tokio-console. I'm unsure which step we should take first when we're trying to start the client. Perhaps we should watch the stats first? Or should we only watch the stats after we receive the first update?

[hds]

@Rustin170506 I think this is the right approach.

To integrate this with Tokio-Console, I would get the State stream from WatchState and include it in the tokio::select! statement in main():

console/tokio-console/src/main.rs

Line 81 in f8e1bee

tokio::select! { biased;

To make the UI "reactive" even in the event of network slow down, we may want to have some additional states in Tokio Console for "pausing" and "unpausing" which would be set in between the user pressing the space bar and the new state being received from the State stream.

Does that make sense?

[Rustin170506]

To integrate this with Tokio-Console, I would get the State stream from WatchState and include it in the tokio::select! statement in main():

The issue at hand is that when we call next_event, it attempts to connect to the server within the function. However, since we've introduced a new API, we're unsure about when we should monitor this new API. Should we have next_event establish the connection first, or should we update the logic to monitor the state API and establish the connection simultaneously?

[hds]

My thought was to do it all simultaneously.