Add legacy operations for multi-path scenario

[pshao25]

To proceed #234, add the legacy operation template into the library according to this design. It's almost the same as @markcowl 's design, except:

1. Change the body name and doc for CustomPatchSync/CustomPatchAsync to align with those of ArmCustomPatchSync/ArmCustomPatchAsync.
2. Change the DeleteAsync to DeleteWithoutOkAsync because its corresponding ArmResourceDeleteAsync is deprecated.

[azure-sdk]

All changed packages have been documented.

• ✅ @azure-tools/typespec-azure-resource-manager

Show changes

@azure-tools/typespec-azure-resource-manager - feature ✏️

Add legacy operations for multi-path scenario

[azure-sdk]

You can try these changes here

🛝 Playground	🌐 Website	📚 Next docs

[markcowl]

I wonder if we want to export the types here as experimental until we have used them on a few more specs.

[pshao25]

I wonder if we want to export the types here as experimental until we have used them on a few more specs.

Isn't the design ready? What else we need to design more? If we don't get this in, every time when customer asks, we need to give them a copy of a legacy operation.

[AlitzelMendez]

I wonder if we want to export the types here as experimental until we have used them on a few more specs.

do you mean like having an Azure.ResourceManager.Experimental?

[markcowl]

I think we want to add two add an additional parameter for every one of these operations that has a request body, like:

RequestBody extends {} = {
  @doc("The content of the action request")
      @bodyRoot
      body: Request
},

This would allow optional request bodies, which are not standard, but occur in legacy apis

[markcowl]

It also allows renaming the body parameter without decorators.

[markcowl]

I'd like us to be explicit that these APIs are subject to change, and should only be used in converting legacy APIs to typespec.

If we could, I would consider an experimental types export like this: https://github.com/microsoft/typespec/blob/main/packages/events/package.json#L28

But we would have to validate that this works with imports and standard tsp compilation. The best current solution might be docs and either a decorator or rule that marks these types as volatile, and issues a warning if you use them (perhaps through conbining a decorator and linting rule, so that it could be globally suppressed in config).