Correctly initialize use allow list and use block list parameters on the access list predicates

[Stefan-Ethernal]

Description

In case either bridge allow list admin or bridge block list admin is provided, predicate contracts are initialized with flags that indicate that both bridge transactions allow list and block list should be checked.

This was wrong because if someone configures Supernets to rely only on the bridge block list (by specifying the bridge block list admin address), SC will also check the allow list. Since the bridge allow list is empty it would result in the account not being able to execute bridge transactions, even though it is not block-listed.

Therefore, the fix includes using separate boolean parameters to initialize SCs whether allow list or block list should be used.

Existing data fix

If bridge transactions are not executed successfully (either deposit for child chain mintable tokens or withdraw for root chain mintable tokens), and access lists are in use, chances are the issue is related to this bug.
In order to fix it the following Foundry commands need to be run (https://book.getfoundry.sh/reference/cast/cast-send).

Use only block lists for bridge transactions

In case only bridge block lists should be used, an account that was specified as bridge block lists admin during deployment should send the following transactions, which would disable usage of allow lists on the predicate contracts:

$ cast send --private-key <owner private key> --rpc-url <Supernets JSON RPC URL> --legacy --gas-limit 100000 0x0000000000000000000000000000000000001004 "function setAllowList(bool)" false
$ cast send --private-key <owner private key> --rpc-url <Supernets JSON RPC URL> --legacy --gas-limit 100000 0x0000000000000000000000000000000000001006 "function setAllowList(bool)" false
$ cast send --private-key <owner private key> --rpc-url <Supernets JSON RPC URL> --legacy --gas-limit 100000 0x0000000000000000000000000000000000001008 "function setAllowList(bool)" false
$ cast send --private-key <owner private key> --rpc-url <Supernets JSON RPC URL> --legacy --gas-limit 100000 0x0000000000000000000000000000000000001009 "function setAllowList(bool)" false
$ cast send --private-key <owner private key> --rpc-url <Supernets JSON RPC URL> --legacy --gas-limit 100000 0x000000000000000000000000000000000000100a "function setAllowList(bool)" false
$ cast send --private-key <owner private key> --rpc-url <Supernets JSON RPC URL> --legacy --gas-limit 100000 0x000000000000000000000000000000000000100b "function setAllowList(bool)" false

Use only allow lists for bridge transactions

In case only bridge block lists should be used, an account that was specified as bridge block lists admin during deployment should send the following transactions, which would disable usage of block lists on the predicate contracts:

$ cast send --private-key <owner private key> --rpc-url <Supernets JSON RPC URL> --legacy --gas-limit 100000 0x0000000000000000000000000000000000001004 "function setBlockList(bool)" false
$ cast send --private-key <owner private key> --rpc-url <Supernets JSON RPC URL> --legacy --gas-limit 100000 0x0000000000000000000000000000000000001006 "function setBlockList(bool)" false
$ cast send --private-key <owner private key> --rpc-url <Supernets JSON RPC URL> --legacy --gas-limit 100000 0x0000000000000000000000000000000000001008 "function setBlockList(bool)" false
$ cast send --private-key <owner private key> --rpc-url <Supernets JSON RPC URL> --legacy --gas-limit 100000 0x0000000000000000000000000000000000001009 "function setBlockList(bool)" false
$ cast send --private-key <owner private key> --rpc-url <Supernets JSON RPC URL> --legacy --gas-limit 100000 0x000000000000000000000000000000000000100a "function setBlockList(bool)" false
$ cast send --private-key <owner private key> --rpc-url <Supernets JSON RPC URL> --legacy --gas-limit 100000 0x000000000000000000000000000000000000100b "function setBlockList(bool)" false

Changes include

• Bugfix (non-breaking change that solves an issue)
• Hotfix (change that solves an urgent issue, and requires immediate attention)
• New feature (non-breaking change that adds functionality)
• Breaking change (change that is not backwards-compatible and/or changes current functionality)

Checklist

• I have assigned this PR to myself
• I have added at least 1 reviewer
• I have added the relevant labels
• I have updated the official documentation
• I have added sufficient documentation in code

Testing

• I have tested this code with the official test suite
• I have tested this code manually

[vcastellm]

LGTM