Define Poller in azure_core::http

[heaths]

As part of the big refactoring for beta.2, I not only moved the LRO stuff but renamed it. Seems I forgot to move Lro to a Poller object...or maybe we didn't even have that before and needed to implement that yet. All the support types and functions are there.

[heaths]

I'm thinking this is just a custom implementation of a Future where the poll method will use Retry-After or whatever - like we do in other languages - to set a timeout for the waker to poll again. To run the task we can use the task spawner @LarryOsterman wrote.

[heaths]

For reference, legacy generates these each time:

azure-sdk-for-rust/services/svc/keyvault/src/package_7_5/mod.rs

Line 1423 in dce289d

fn into_future(self) -> Self::IntoFuture {

Need to prototype some options because I'm not sure if actually defining a Poller<T> that implements Future<T> or IntoFuture<T> really adds anything apart from the ability to hand additional functions off it.

/cc @analogrelay in case she has any thoughts.

[analogrelay]

I do like the idea of being able to directly await a Poller, as long we also properly support cancellation via Drop. That would allow a poller to act like any other future and use all the existing timeout/cancellation patterns in rust.

[heaths]

Good thing to test, yeah (about Drop). As I was thinking about this more this morning, I figured we'd probably construct one much like we do a Pageable<T>, which also takes a couple of functions, and Poller<T> would implement Future or IntoFuture itself.

We should probably implement Future. According to the docs:

Implementing Future is a good choice in most cases. But implementing IntoFuture is most useful when implementing “async builder” types, which allow their values to be modified multiple times before being .awaited.

[heaths]

Talking with @JeffreyRichter about Go's Poller[T], a few things of note:

1. Do not return the final model. Not only are there many patterns for this across services that make it difficult to support, it's not always possible in some cases e.g., Key Vault's create certificate endpoint.
2. Allow serialization of the status monitor.
3. Allow rehydration.
4. Support customers varying the retry. Probably not worth using our existing RetryOptions, but something probably similar. We should use the retry-after header if services send it. IIRC, there is 1 or 2 custom headers older services may send.