Azure core poller flux to support context passing

[samvaity]

Update the current implementation of PollerFlux to support context passing for callback operations.

[samvaity]

@anuchandy Do you know if we would be able to get this in to start supporting context passing in LRO's for Form recognizer this beta?

[anuchandy]

@samvaity like we discussed offline I'm starting on it today, will open a pr soon.

[anuchandy]

Sharing the update so far:

"Async" PollerFlux

PollerFlux is a Flux that users can subscribe with Reactor.Context. This reactor context is automatically available for activation/poll/getFinalResult functions, these functions could just use FluxUtils.withContext (to convert to Azure.Context) and make the raw service method call inside it. I think no issue exists in async space.

SyncPoller

In sync APIs we don't have a way to pass Azure.Context. We need to understand the granularity of control we need to provide via context. Depending on the scope of control, the context could be global to a single SyncPoller or can local to methods in SyncPoller or both. This design depends on clarity on use cases:

1. The tracing for LRO.
   --> Tracking issue - [Design] Tracing story for LRO #10969. It is opened for PollerFlux but decisions should cover SyncPoller as well.
2. The need for cancellation support for APIs exposed in SyncPoller.
   --> require understanding of [in-progress] sync cancellation feature.
3. The telemetry of these APIs exposed in SyncPoller.

\\cc @JonathanGiles

[weidongxu-microsoft]

One complexity about PollerFlux is that after subscriberContext, it is no longer of class PollerFlux, but only a Flux.

This might be an issue, since caller now lose the flexibility of either use the async, or convert it to sync poller via getSyncPoller from PollerFlux.

I am pondering whether to add a Context at parameter to our builder of PollerFlux, so it would subscribe that Context to all its 4 operations (similar granularity question arises as for SyncPoller), while still returns the PollerFlux.