Fix merge_registries to account for same contract names across different chain ids

[derekpierre]

It is possible to have the same contract name repeated across different chain ids. The initial set-up for the merge_registries() function placed all registry entries from a registry file into a dictionary keyed by name. However, some entries can get lost this way, because the dictionary is keyed by name and contract names can be repeated across different chains eg. ProxyAdmin. Therefore some registry entries don't end up in the merged contract registry.

This PR accounts for common names across the registry in different chains. The ridiculous test was to try to merge lynx.json and tapir.json (a ridiculous example yes, but great for testing). The merged registry should have all entries for chain id 5 from lynx.json, all entries from chain id 11155111 from tapir.json (those 2 chains are non-conflicting), and then conflicts for 80001 which you can test resolving appropriately.

If the above test is run with the old code some registry entries (with dupe names across different chains) are not included for some chains. ProxyAdmin is the worst offender because it is an entry in all chains (5, 11155111, 80001).

Try it out, both with/without the change:

$ ape run merge_registries --registry-1 ./deployment/artifacts/lynx.json --registry-2 ./deployment/artifacts/tapir.json -o ./merge.json

[KPrasch]

On the "green path" we'd deploy a contract, then replace it in the old registry, right? This implies that the merge is one-way, so It may be useful to have an alternate strategy to "update" a base registry with a patch, instead of an interactive flow. This can be achieved with some optional parameters here in your function to always select resolution 1 or 2. You might even make this function private and then wrap it with differently parameterized calls. Not a blocker, just commentary (ps let's not reinvent git 😆 ).

def _perform_merge(...):
    ...
    
def interactive_merge(reg1, reg2):
    ...
    
def one_way_merge(patch, base, ...):
    ...

[derekpierre]

Yeah that's a good point. I guess for some conflict resolution it won't be a 2nd filepath, just an updated contract to add to the registry at the end of an updated deployment eg. we update the Coordinator contract for Lynx.

We could handle that in a follow-up change.

[derekpierre]

Filed #151 .

[theref]

Will this be affected by the fact that we have a new domain?: dashboard which has chain id 5, the same as lynx

[derekpierre]

Will this be affected by the fact that we have a new domain?: dashboard which has chain id 5, the same as lynx

It's not a real TACo domain (lynx, tapir, mainnet), is it? I assumed dashboard was a staking dashboard specific thing...does it have effects outside of the staking dashboard?

[KPrasch]

Will this be affected by the fact that we have a new domain?: dashboard which has chain id 5, the same as lynx

No, lynx and dashboard are separate domains so they are not exposed to these merge utilities.