Remove internal RLC layer from modular

[timovv]

This PR removes the rest/ directory from the modular generator. There is no significant change in the public API and the runtime serialization logic remains the same.

Key points:

• Removed references to RLC models in the internal operation send and deserialize functions. The send functions now return a PathUncheckedResponse, and the deserialize functions accept a PathUncheckedResponse instead of the RLC model types. The actual API methods still accept and return the API layer models.
• In the deserialize functions, instead of using isUnexpected, the status code of the response is now checked inline against a list of expected status codes.
• The context factory function now calls getClient from @azure-rest/core-client directly instead of creating an RLC client from the REST layer.
  • Things that the RLC getClient used to do, such as adding the custom API version policy and/or key credential policy, are now done inline in the context factory function.
  • The ClientContext interface is now declared in the API layer as an interface extending Client from @azure-rest/core-client, instead of being a re-export of the RLC definition. 
• Extracted and redefined some RLC utilities (e.g. the logger and collection builders) that are being used by the Modular code.

After this PR, the actual emitted Modular code will not contain anything generated by the RLC emitter, excluding metadata the README and package.json. However, the emitter still relies on the RLC code model to construct the Modular code model. I plan to follow up on decoupling from the RLC code model and metadata generation shortly after this PR.

Fixes #2725.

[joheredi]

I think this is looking really good

[qiaozha]

thanks for taking care of this

[qiaozha]

feel like we might have missed the default logic handling for other parameters

[qiaozha]

https://github.com/timovv/autorest.typescript/blob/62159e3252799f32b10629a79dcb3d2552fd219d/packages/rlc-common/src/buildClient.ts#L319-L347

[timovv]

I think this is covered here but let me know if there's something missing in that logic:

https://github.com/timovv/autorest.typescript/blob/62159e3252799f32b10629a79dcb3d2552fd219d/packages/typespec-ts/src/modular/helpers/clientHelpers.ts#L79-L93

[qiaozha]

the default value was handled in

autorest.typescript/packages/typespec-test/test/parametrizedHost/generated/typespec-ts/src/rest/parametrizedHostClient.ts

Lines 30 to 32 in dd505de

	const host = options.host ?? "one";
	const subdomain = options.subdomain ?? "two";
	const sufix = options.sufix ?? "three";

and currently it's missing in https://github.com/timovv/autorest.typescript/blob/62159e3252799f32b10629a79dcb3d2552fd219d/packages/typespec-test/test/parametrizedHost/generated/typespec-ts/src/api/parametrizedHostContext.ts#L22-L25

[qiaozha]

I also think this kind of default value change can not be catched by the api view.md @joheredi this is a potential risk if we just check in the api view.md file.

[qiaozha]

I don't think this is correct, we should respect the parameter default in the @server decorators, that's why we should respect the endpoint default value, also in this case, those parameters are parts of the endpoint

autorest.typescript/packages/typespec-test/test/parametrizedHost/generated/typespec-ts/src/rest/parametrizedHostClient.ts

Lines 30 to 36 in dd505de

	const host = options.host ?? "one";
	const subdomain = options.subdomain ?? "two";
	const sufix = options.sufix ?? "three";
	const endpointUrl =
	options.endpoint ??
	options.baseUrl ??
	`${host}.${subdomain}.${sufix}.com/${apiVersion}`;

In this case, if we don't populating the clientDefaultValue, those parameters should be required and go into the getClient method signature instead of options.

[timovv]

Can you give an example of what this example should look like?

[timovv]

Is the issue here that apiVersion isn't getting a default value when it should be? Or is there something else that is also not being considered?

[qiaozha]

This is the typespec definition

autorest.typescript/packages/typespec-test/test/parametrizedHost/spec/main.tsp

Lines 20 to 32 in dd505de

	@server(
	"{host}.{subdomain}.{sufix}.com/{apiVersion}",
	"Confidential Ledger Service",
	{
	@path
	host?: string = "one",
	@path
	subdomain?: string = "two",
	@path
	sufix?: string = "three",
	@path
	apiVersion?: string = "v1"
	}

, we ignore clientDefaultValue for everywhere else but this @server decorator.

if we choose to ignore the default value for it, then we should not handle the default value for endpoint or apiVersion either. the createParameterizedHost function should be like

export function createParametrizedHost(
  credential: TokenCredential,
  host: string,
  domain: string,
  suffix: string,
  apiVersion: string,
  options: ParametrizedHostClientOptionalParams = {},
): 

There're some more context here for how to handle endpoint and how to handle the clientDefaultValue
#2032 (comment)
#2049

[qiaozha]

Is the issue here that apiVersion isn't getting a default value when it should be? Or is there something else that is also not being considered?

we have the default value for apiVersion https://github.com/Azure/autorest.typescript/pull/2561/files#diff-c381779e571bb42446df22900b2c16f1f7036a24f71042ac0bd83e4ef47ff630R28

[qiaozha]

why this is removed?

[timovv]

The reason this header value was being set seems to be because the isUnexpected helper was using it. Since we're not using isUnexpected anymore I think it's ok to remove. Unless there's another place where we're using this value I don't know about?

[qiaozha]

@wanlwanl I thnk we need to change the version detection logic accordingly, after this pr get merged from src/rest/XXXClient.ts to src/api/XXXContext.ts