Embrace native Effect RPC

[patroza]

effect-app uses a relatively thin layer around Effect RPC, adding the following changes:

• "Dynamic" middleware, based on configuration living on each Request. so instead of imperatively adding middleware to every RPC / Group, you configure it on a Request definition. e.g allowAnonymous?: true will require a user for all endpoints, except those configured with allowAnonymous: true, idem with basic role requirements, e.g the default is to require admin access, unless you specify only the user role is required. Each dynamic middleware can either optionally provide context, or add to the Failures of an RPC
• Wrapping/Providing middleware on the global level; so not just per RPC or group, but for all.
• Providing middleware can provide Context; so more than 1 service at a time.
• a different API to define Controllers, and to use derived clients, with less ceremony to define rpcs and implement controllers (like there's the namespace auto derived from the folder structure)
• we do not support middleware that also affects the client, apart from Dynamic Middleware adding failure types to the RPCs.
• we support "bare" generator functions for controller handlers (instead of requiring (x) => Effect.gen(function*() or Effect.fnUntraced(function* (x) wrapping

on the middleware level we are much more aligned now, except for the Dynamic Middleware.

TODO

• look into switching our Generic/Providing middleware for native RPC Wrap/Provide middleware, perhaps at first just using the Middleware tag constructors from RPC.
• consider replacing our resources/controllers/derived clients approach with native Effect RPC
  • alternatively, consider supporting middleware passed to Router() or match() so we can support middleware on the controller level too
• fluent apis
• add provides: Context.Context support. (actually provides: [X, Y, Z], which requires returning a Context)
• add support for requires (the opposite of provides) RPC Middleware: play with requires #293
• look into what can be ported to or requested to be added to Effect RPC
  • port provides: [X, Y, Z] Context feature. https://github.com/Effect-TS/effect/pull/5328/files
  • port requires (seems harder due to the RpcGroup/toLayer api)
  • port multi middleware add once, including sideways elimination..
  • port global/dynamic middleware; derive an RpcGroup make and toLayer from prepared middleware.
    • global
    • dynamic (based on configuration on the Request)
• align more to middleware as first class citizen
• remove http details from rpc api: 8cc79f2

[patroza]

progress: #290

[patroza]

and add support for RpcProtocol dependencies support like HttpRouter.Providedas Required context. or consider to do this differently; an RpcProtocol middleware that extracts things from specific protocols, and then provides a generic service to the middleware/rpcs. do we even need it? the only access we have right now is at

libs/packages/infra/src/api/internal/RequestContextMiddleware.ts

Line 10 in 219804e

const req = yield* HttpServerRequest.HttpServerRequest

- which is a server middleware anyway, and not rpc. RPC really shouldn't be accessing Http details!

-> remove http details from rpc api: 8cc79f2

[patroza]

Inching closer to embrace, and have a concept for Dynamic Middleware more aligned with Effect RPC.
The piece that's missing is an RpcGroup.toLayer version that includes the generic and dynamic middleware and eliminates the context accordingly.
e9ce960