Clientcore poller design considerations

Reference PR - https://github.com/Azure/azure-sdk-for-java/pull/44670

Comments from @alzimmermsft

1. Race conditions in chained polling strategy
> Can ChainedPollingStrategy be re-used in multiple locations? If it can, we may need to harden this method to prevent race conditions from happening.

2. Revisit polling strategy constructors and order of evaluation of polling strategies
> Do we have any concerns with the design of this type? Such as the opinions on which strategy are included here and with which order they are?

3. Customizable headers for `OperationResourcePollingStrategy`
> Why don't we provide a way to set the HTTP header inspected by OperationResourcePollingStrategy in any of these constructor methods?

4. PollingContext redesign
> Now that we're given a chance to make breaking changes, is there anything we'd want to change about PollingContext? Possibly elevating some key-value pairs in this Map to typed properties on this class?

5. Do we need the Poller interface?
> Do we need to have an interface and class for implementing polling? Could we instead just use SimplePoller directly in public API?

6. Expandable enum caching
> If we're not going to cache instance created here we don't really need to use a backing Map to store constants defined by the ExpandableEnum. Rather we could do simple string equivalence checking that'd should be more performant as map usage will require scanning name at least once for its hash to determine the map bucket and zero to a few times to compare it against keys found in the bucket. This logic would be a basic initial check on name.length() matching known lengths, if not matched we know this is new, and then casing on length matches to do direct value comparisons.

Inizia esaminando la PR di riferimento 44670 e gli entry point indicati ChainedPollingStrategy, OperationResourcePollingStrategy, PollingContext, Poller, SimplePoller ed ExpandableEnum. Confronta le sei domande di progettazione con l’implementazione corrente di clientcore; il lavoro è completato quando le decisioni sull’API e qualsiasi ambito di follow-up sono definiti esplicitamente.

Scritto dal modello di indicizzazione a partire dal testo della issue.