Introduce more usages to describe things related with the states of LRO

[ArcturusZhang]

Remove this workaround since #311 is closed.
Fixes #1752
Fixes #1530

This PR adds three new usage flags: LroInitial, LroPolling, LroFinalEnvelope.
These new usage flags are previously represented by Output, now the Output flag no longer contain the semantics of these usages.
Therefore, if a model's usage is only LroInitial, this means it is only used as the initial response of an LRO.
if a model has both LroInitial and Output, this means it is used as the initial response of an LRO, and it also used as a normal output in other places.
The final result will not have above new usages unless it participates as those roles as well. It will have output usage.

[azure-sdk]

All changed packages have been documented.

• ✅ @azure-tools/typespec-client-generator-core

Show changes

@azure-tools/typespec-client-generator-core - feature ✏️

1. Introduce new usage: LroInitial, LroPolling, LroFinalEnvelope.,> 2. usage and access now properly propagate on polling model, final result and final envelop result of lroMetadata.

[azure-sdk]

You can try these changes here

🛝 Playground	🌐 Website	📚 Next docs

[iscai-msft]

@ArcturusZhang are you ok with this being released as part of the november release? in 2 weeks? If so, I would merge into main. If you'd like us to release this before the big release, can you merge into our release branch release/november-2024 and let us know, then we'll do a tcgc release for you. Thanks for your contribution!

[haolingdong-msft]

The changes in this pr looks good to me. Just want to bring up this related issue: #1750 - If TCGC keeps the current usage and access for LRO intial response, we should have a way to let emitter know when to update access and do not generate this model. But this will make TCGC's access less helpful as emitter still need to update it based on usage.

[ArcturusZhang]

I think per discussion this morning, maybe it is better that we could introduce some new usages for these lro related models since they have different context to use.

Is there any issue to track? (my created issue is closed as planned, feel free to reopen it)

i think we could do the usage split in this pr. @ArcturusZhang thoughts?

yeah I will update those in this PR

[weidongxu-microsoft]

I don't have opinion on this in Java. You can go ahead if no objection from other languages.

I assume the usage is additive. Meaning we cannot know whether a model is "only used in LroInitial"?

[ArcturusZhang]

I don't have opinion on this in Java. You can go ahead if no objection from other languages.

I assume the usage is additive. Meaning we cannot know whether a model is "only used in LroInitial"?

not quite additive.
The new usage (for example LroInitial) is part of the old Output. New Output no longer contains LroInitial.
Therefore if you see one model only has LroInitial, this means this model is only used as the initial response of an lro. The output now means everything other than those have an explicit definitions such as the lro initial.

[weidongxu-microsoft]

not quite additive. The new usage (for example LroInitial) is part of the old Output. New Output no longer contains LroInitial. Therefore if you see one model only has LroInitial, this means this model is only used as the initial response of an lro. The output now means everything other than those have an explicit definitions such as the lro initial.

Got it. So only the "final result" would still be marked as usage=Output?

nit, maybe we can call it e.g. OutputLroInitial (kind of grouping the "output" family)?

[ArcturusZhang]

not quite additive. The new usage (for example LroInitial) is part of the old Output. New Output no longer contains LroInitial. Therefore if you see one model only has LroInitial, this means this model is only used as the initial response of an lro. The output now means everything other than those have an explicit definitions such as the lro initial.

Got it. So only the "final result" would still be marked as usage=Output?

nit, maybe we can call it e.g. OutputLroInitial (kind of grouping the "output" family)?

I think it is a good idea to emphasize. what do you think on this suggestion? @tadelesh
An issue would be there are already some usage is part of the input usage but not named in this way (for instance jsonmergepatch)

[tadelesh]

not quite additive. The new usage (for example LroInitial) is part of the old Output. New Output no longer contains LroInitial. Therefore if you see one model only has LroInitial, this means this model is only used as the initial response of an lro. The output now means everything other than those have an explicit definitions such as the lro initial.

Got it. So only the "final result" would still be marked as usage=Output?
nit, maybe we can call it e.g. OutputLroInitial (kind of grouping the "output" family)?

I think it is a good idea to emphasize. what do you think on this suggestion? @tadelesh An issue would be there are already some usage is part of the input usage but not named in this way (for instance jsonmergepatch)

i'm thinking of separating the usage into two layers, which means:

1. for first layer, we label them all as input, output, etc.
2. for second layer, we separate output to something like:

enum OutputUsage {
  Normal,
  LroInitial,
  Error,
  ...
}

that will be a breaking change, but much extensible and we should make sure each layer orthogonal. idk if there is good data structure could do that, just a quick thought.
loop in @iscai-msft for thoughts.

[tadelesh]

open this issue to track usage refactor: #1941