Runtime update detector

[Niederb]

• Adds a class that allows to wait for runtime updates
• Not sure if extracting the trait UpdateRuntime was worth it
• The design and features are somewhat limited by the fact that we don't want to use a &mut reference of Api
• I implemented two examples: sync and async. I tried with having only one but the examples ended up somewhat confusing. So I separated them.
• Canceling the future is not handled inside of RuntimeUpdateDetector but instead in the example
  • The could not find a simple way of doing it without relying on Tokio and using Tokio would restrict the runtime choice of the user
• I'm not super happy about the implementation for canceling the RuntimeUpdateDetector but I thought it is neccessary
  • Note that it is not bulletproof for the sync case. This is due to the fact that getting the events is blocking with no option of canceling the wait. So if no more events are received the call is still stuck

[haerdib]

I really like the function detect_runtime_update. That's great, thanks a lot! I'm not yet sure about the examples - maybe we can do better there.

[haerdib]

Regarding the problem with the cancellation token: Subscription allows for "unsubscribe":

substrate-api-client/src/rpc/mod.rs

Lines 68 to 81 in 4d4f198

	#[maybe_async::maybe_async(?Send)]
	pub trait HandleSubscription<Notification: DeserializeOwned> {
	/// Returns the next notification from the stream.
	/// This may return `None` if the subscription has been terminated,
	/// which may happen if the channel becomes full or is dropped.
	///
	/// **Note:** This has an identical signature to the [`StreamExt::next`]
	/// method (and delegates to that). Import [`StreamExt`] if you'd like
	/// access to other stream combinator methods.
	async fn next(&mut self) -> Option<Result<Notification>>;
	/// Unsubscribe and consume the subscription.
	async fn unsubscribe(self) -> Result<()>;
	}

Maybe I'm imagining things a little easier than they are, but: If the subscription is made public, or a respective function is implemented, one could unsubscribe, and break the loop by having .next_events_from_metadata() return None. That would resolve the problem with the sync version and make the cancellation token obsolete. Could that work?

[Niederb]

Hmm, it might work. I'm not quite sure what happens with waiting subscriptions when we unsubscribe. Anyway I think I would rather look at this in a follow up task.

[haerdib]

Agreed, lets investigate that in another issue

[Niederb]

I created #638 as a follow up

[haerdib]

Agreed, lets investigate that in another issue

[haerdib]

Almost there! Just one thing left regarding the async example. Other than that, I think it's good to go 🥳 Thanks for your patience!

[haerdib]

Thanks for your patience with me! 💯