Move resource abstraction to `@cadl-lang/resource` (aka resource reform)

[bterlson]

Right now, the resource abstraction is mixed in with the Rest library, but to my eyes, resources are a protocol-agnostic pattern. If the resource abstraction uses no REST terminology it should be possible to emit some canonical resource pattern in both gRPC and Rest for example.

Likewise, this feels like the natural place to "own" the visibility semantics - the precise set of flags supported, and functionality to apply those flags to model types for use in emitters. If we use enums and enum references, this allows other resource abstractions (or database ORM generators or whatever) to establish their own set of visibility flags without conflict.

With this, a simple resource that supports emitting to gRPC and Rest might look like:

import "@cadl-lang/resource";
import "@cadl-lang/http";
import "@cadl-lang/grpc";

@serviceTitle("Widget Service")
namespace DemoService;

using Cadl.Http;
using Cadl.Resource;
using Cadl.gRPC;

model Widget {
  @field(1) @key id: string;
  @field(16) weight: int32;
  @field(17) color: "red" | "blue";
  @field(18) @visibility(Visibility.Create) password: string;
}

@error
model Error {
  @field(1) code: int32;
  @field(2) message: string;
}

interface WidgetService extends Resource.ResourceOperations<Widget, Error> {
  @get @route("customGet") customGet(): Widget;
}

[daviwil]

I'm certainly in favor of this. I've got ideas in mind for how we can remove all references to resource typings in rest/route.ts and pass through the resource action -> HTTP verb mappings.

We may need to consider an alternate decorator strategy for marking the parameters of standard resource operations without HTTP-specific concepts. I think I had proposed this at some point before but I don't remember the issue.

[markcowl]

• visibility mechanism
• protocol-agnostic representation of resource estimate: 8