ClientModel prototype: LRO abstractions using the "struct" approach

[annelo-msft]

This approach explores adding a third LRO type representing the tuple of status and value for a progressively-resolved result of a service LRO.

Note its similarity to Page in the pageable abstraction set.

This adds a lot of implementation complexity, and makes you implement polling in something that's essentially a model type. Doesn't seem better than #44275

I guess the question is - is there value in having a separate type like page that holds the individual response and some additional meta-data about the operation that's at a lower-level of abstraction. That fact that you access it through Operation.Value seems kludgy and awkward, though. If we let you access it through a different method like "AsPages" might hide the complexity, but I think would also require you to either pass the status type parameter (I wouldn't expect this to be discoverable), or somehow specify the type parameter in the top-level type, which we're trying to avoid.

[azure-sdk]

API change check

APIView has identified API level changes in this PR and created following API reviews.

System.ClientModel

[github-actions]

Hi @annelo-msft. Thank you for your interest in helping to improve the Azure SDK experience and for your contribution. We've noticed that there hasn't been recent engagement on this pull request. If this is still an active work stream, please let us know by pushing some changes or leaving a comment. Otherwise, we'll close this out in 7 days.