Hide PermissionController state from third parties

[rekmarks]

When successful, wallet_getPermissions and wallet_requestPermissions both return the current permissions for the requesting subject, which is a subset of the permission controller's state. This is very unfortunate, because it means that we are externalizing the state of an otherwise internal module, and makes changes to its state breaking changes of our public API. In preparation for the introduction of a multichain API and its new permissions (see #4241), we should introduce an adapter function between the permission controller at the RPC methods that return its state.

This adapter function should take the permission controller state and return a public representation thereof, perhaps modeled on what we already do for Snaps manifest permissions. We can then ship this public state representation as part of our API, and do whatever we want with our internal state. This public representation should focus on what's strictly necessary for the consumer to understand the authority they've been granted, and nothing more. In particular, it should not contain any ZCAP-LD properties or make mention of caveats, all of which we should regard as implementation details.

Complication: window.ethereum

Of course, we have already shipped our current internal state via window.ethereum (and potentially the Snaps provider). The adapter must be written such that, for interfaces that support wallet_getPermissions and wallet_requestPermissions they return the same state that they do today, unmodified. If necessary, they can support newly introduced permissions as well, but we cannot break this APIs for existing consumers, and especially consumers of window.ethereum.

[vandan]

Hey team! Please add your planning poker estimate with Zenhub @adonesky1 @BelfordZ @shanejonas

[vandan]

Migration should also be addressed along with this change: https://github.com/MetaMask/MetaMask-planning/issues/2530