Add address lookup table to find contract task/name

[TomAFrench]

Description

builds on #2030

Given a deployment task and contract name, it's currently easy to lookup the onchain address for that contract. What's more difficult however is given an onchain contract address, check to see if it's a Balancer-deployed contract and if so return the task id and contract name.

This PR generates a lookup table for this operation which makes it easier to generate human-readable identifiers for contracts when starting from onchain data. It currently only handles contracts which are directly deployed (i.e. Pool factories but not Pools themselves) as the initial usecase for this map (tracking addresses which hold permissions on the authorizer) doesn't require this.

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

[nventuro]

I understand wanting to have this, but wouldn't a better way be to load all output files for all tasks in said network, and search for the address there? It'd mean we don't need to maintain these json files (which we'd need to check for correctness if we kept them).

[nventuro]

We already have this task-output looping behavior when checking deployments for a network.

[TomAFrench]

I understand wanting to have this, but wouldn't a better way be to load all output files for all tasks in said network, and search for the address there? It'd mean we don't need to maintain these json files (which we'd need to check for correctness if we kept them).

This is a bit nasty when you're dealing with many addresses. For every address you want to check you need to find all the deployment tasks, iterate through them loading the output json files and then iterate through every key-value pair to find one with the correct value. We need to do a lot more work than if we just precompute the result of that and save it here so we're just looking up a key in a mapping.

That said, we could use that method to compute this mapping at build-time rather than at deployment like this PR currently does. I'd still want a CI action to ensure this is up to date though.

[nventuro]

What is the use case for this? If we don't care that much about performance, then having way simpler code seems like a good idea, instead of having to maintain the build list code, check list code, etc.

[TomAFrench]

I think shifting this code to index.ts would increase code complexity. We have a lot of helpers for manipulating the task data which we can use internally but whereas we'd get more brittle and harder to maintain code by redoing this in index.ts

[TomAFrench]

What is the use case for this?

The initial usecase is for it to be used in the permissions package in so we can label addresses with permissions more easily.