Begin adding tracking for "real world" state of permissions granted onchain

[TomAFrench]

Description

This PR starts the creation of the v2-permissions package which includes various scripts which aim to pull the current state of the Authorizer from onchain (through a subgraph) and reconstruct a human readable representation of the permissions which have been granted.

Using the subgraph we can get a list of addresses and for each address a list of action ids which they have permissions over. We can then map from action ids to a list of contract-function pairs which it allows them to call, and from addresses to a human readable name, e.g.

{
  "GNOSIS_PROTOCOL_RELAYER": [
    {
      "taskId": "20210418-vault",
      "contractName": "Vault",
      "signature": "manageUserBalance((uint8,address,uint256,address,address)[])",
      "useAdaptor": false
    },
    {
      "taskId": "20210418-vault",
      "contractName": "Vault",
      "signature": "batchSwap(uint8,(bytes32,uint256,uint256,uint256,bytes)[],address[],(address,bool,address,bool),int256[],uint256)",
      "useAdaptor": false
    }
  ],
  "BLABS_VEBAL_MULTISIG": [
    {
      "taskId": "20220325-bal-token-holder-factory",
      "contractName": "BALTokenHolder",
      "signature": "function withdrawFunds(address,uint256)",
      "useAdaptor": false
    }
  ],
}

The state of this package is very rough and will be refined but I want to share it early to help with verifying #1993

1. Verify that all action ids in permissions/unrecognised.json are unnecessary and then renounce/revoke them.
2. Sanity check that permissions/functions.json is a desirable end state for the system to be in post-migration.
3. Ensure that the permissions/actionIds.json matches the input to the authorizer migration deployment task
   • This isn't 1:1 as the authorizer doesn't currently have a concept of where so we need to check that this is set properly for each action ID in the deployment task.
   • This can also be done less rigorously by just checking permissions/functions.json against the deployment task. This is likely good enough.

Type of change

• Bug fix
• New feature
• Breaking change
• Dependency changes
• Code refactor / cleanup
• Documentation or wording changes
• Other

Checklist:

• The diff is legible and has no extraneous changes
• Complex code has been commented, including external interfaces
• Tests are included for all code paths
• The base branch is either master, or there's a description of how to merge

Issue Resolution

[TomAFrench]

Waiting for #2031 to be merged so we can use it here.

[nventuro]

Fantastic initiative!

[nventuro]

It'd be good if we could also have a short description of what these are, their scope, and potentially even link to gov discussion. We could add a metadata field, or make this a ts file and just write comments

[nventuro]

These are network specific, right?

[TomAFrench]

I'm making this package be mainnet only for the time being we're mostly interested in it for the authorizer migration.

[nventuro]

What if 500 is not enough?

[TomAFrench]

We'd have to do pagination at some point as the graph limits how many responses is returns. We've got much fewer than 500 permissions atm (<50) so I'm not too concerned.

I'll add something to blow up this function if we actually receive 500 accounts.

[TomAFrench]

As we're migrating the authorizer on mainnet but not on L2s we'll need to have support for both authorizers for the foreseeable future. Parking this PR until we update subgraph, etc. appropriately.