Re-architect rpc-cap

[rekmarks]

At the moment, rpc-cap consists of:

• RPC method implementations for requesting and retrieving ZCAP-LD-like permission objects
• A CapabilitiesController (in the vein of @metamask/controllers v1) that stores and and manages said permission objects
• A set of json-rpc-engine middleware that enforce the permissions represented by said permission objects

In other words, rpc-cap is three distinct things in one, confused package. Moreover, it's difficult to integrate with the rest of our stack, as evidenced by the ~700-line extension permissions controller, which is more or less a wrapper for the various components of rpc-cap.

To properly modularize rpc-cap and make it easier to work with, we (minimally) need to:

• Extract the CapabilitiesController into a separate module (PermissionController 2.0 snaps#28)
  • Finish base implementation
  • Finish types
  • Finish tests
• Integrate new permission system into extension (Tracked elsewhere)
  • Replace the extension permission controller with the v2 permission controller
  • Replace the extension permission metadata functionality with the new metadata controller
• Consider whether to stick with ZCAP-LD, or switch to a simpler format
  • We're sticking with it. I claim that we can obtain many of the properties of an object capability system in production, and the alternatives I came up with were not significantly simpler.
  • Old notes:
    • Our use of ZCAP-LD is mostly aspirational, because rpc-cap is ultimately an access control list (ACL), and we do not have the means to implement object capabilities in any real sense.
    • However, the format of our permissions objects is mostly abstracted away from us and our consumers, and it might make a future transition to ocaps easier.
• Extract the middleware into a separate module
• Extract the RPC method implementations into a separate module
  • This includes extracting the requestPermissionsMiddleware into the implementation of wallet_requestPermissions
• Extract pending permission request functionality into ApprovalController and RPC method implementation
  • This requires migrating the ApprovalController to BaseControllerV2. See: Migrate ApprovalController to BaseControllerV2 core#555
• Extract permission metadata functionality into a separate controller (Add SubjectMetadataController snaps#61)
• Make a decision about the extension permissions log

[rekmarks]

Closed by MetaMask/snaps#132