Operation ID changed after tsp 0.61

[archerzz]

Description

In tsp 0.60 and prior, getResourceOperation will return undefined for some mgmt cases, like

autorest.csharp/test/TestProjects/MgmtTypeSpec/foo.tsp

Lines 10 to 15 in ab56c7d

	@resource("foos")
	model Foo is TrackedResource<FooProperties> {
	...ResourceNameParameter<Foo, SegmentName = "foos">;
	...ExtendedLocationProperty;
	}

So, previous the ResourceName is Foos which is the interface name:

autorest.csharp/test/TestProjects/MgmtTypeSpec/foo.tsp

Line 36 in ab56c7d

interface Foos {

But in 0.61, getResourceOperation can return the resource operation, which seems the correct behavior. However, that will return different ResourceName. Check this PR: https://github.com/Azure/autorest.csharp/pull/5110/files#diff-81dc15d9aacc476e7f1fc431451c064ac2727e5c09cde422e3ddc362b7b57981L2714

I think the upstream actually has fixed an issue, but unfortunately cause regression in some cases.

[archerzz]

The impact of this change is non-trivial. See the regen preview: Azure/azure-sdk-for-net#47714

[archerzz]

After trial and discussion, we thought we could choose to not do this item due to:

• impact of the change
• operation id should soon be history, probably not worth the efforts

We have 3 types of inputs right now. And for each of them, there is a corresponding issue regarding operation id:

1. Swagger: we lose the original operation id during CodeModelConverter. Most of the changes in the regen preview PR are from that. Moreover, since we fix the wrong operation id, we have to fix the wrong configuration in autorest.md. Some configurations use operation id as the key.
2. Pure TypeSpec: there is no operation id in TypeSpec, and we need to figure out how we want to resolve it.
3. TypeSpec converted from Swagger: the way we resolve operation id in TypeSpec will have impact on how we convert Swagger to TypeSpec, so as to keep operation id consistent.

All in all, if we want to fix the operation id, we must have InputOperation.OperationId passed in from Swagger or from TypeSpec emitter, instead of deducing it in the generator. Previously we have discussed about it, and we thought we don't want to do that.

Since there is no obvious negative outcome, maybe we can choose to not do this item.