Add job deploying contracts from dapp-development branch

[michalinacienciala]

There are situations when team developing T Token Dashboard needs to
locally test some functionalities using modified contracts, for example
ones with shorter authorization decrease delay. We decided to create a
dapp-development branch in each of the upstream modules of
threshold-network/token-dashboard CI module, which would store the
code of these modified contracts. In this PR we create a
contracts-dapp-development-deployment-testnet job which deploys the
contracts, creates an NPM package (with dappdev<environment> suffix
an dapp-development-<environment> tag) and publishes it to the NPM
registry. At the end, the job also starts similar deployment for a
downstream module. The job gets triggered only as a result of
workflow_dispath event from a dapp-development branch. Currently
only goerli environment is supported. We don't run system and unit
tests for dapp-development branch, as the tests are not configured to
work with the modified contracts.
Generally, the goal of the changes is to have the full set of
dapp-development-friendly contracts deployed to the NPM registry, so
that the dApp developers could quickly use them by upgrading the
token-dashboard dependencies using yarn upgrade <package-name>@dapp-development-goerli.
If the workflow gets dispatched from a different branch than
dapp-development, the deploy will behave as it used to, publishing
package with deployed unmodified contracts to the NPM registry under
<environment> tag.

TODO:

• Modify the secret for the deployer account in the contracts-dapp-development-deployment-testnet job
• Bump actions to latest versions
• Test the workflow using combined code from Add job deploying contracts from dapp-development branch #119 and [Do not merge] dApp-friendly contract deployment #118 (dapp-development branch)

Refs:
threshold-network/token-dashboard#136
keep-network/keep-core#3121
keep-network/tbtc-v2#392

[michalinacienciala]

I wondered whether to use explicit value (dapp-development) here, or ${{ github.event.inputs.upstream_ref }}. Decided to use the former - it gives us less flexibility, but the general intention is that we always want to run the downstream modules on the same dapp-development branch. And by hardcoding it, we avoid the nasty consequences of the situation when somebody triggers the workflow from dapp-development branch, but with upstream_ref set to a different branch (which, if not for the harcoded value, would result in triggering of a downstream workflow from that different branch, resulting in publishing of goerli-tagged package that uses modified contracts in it's dependencies) .

[michalinacienciala]

I dry-runned the workflow here: https://github.com/threshold-network/solidity-contracts/runs/7561186309?check_suite_focus=true. The workflow passed, but I noticed two things that seem strange to me:

1. Although in contracts-dapp-development-deployment-testnet job I don't have the step that prepares the Tenderly config, somehow the tenderly verification worked. I don't understand that. According to hardhat-tenderly documentation

For this plugin to function you need to create a config.yaml file at $HOME/.tenderly/config.yaml or %HOMEPATH%\.tenderly\config.yaml and add an access_key field to it

Without the step that runs the script preparing that config, the file should not exist and Tenderly should not be able to authorize. But from the logs we see that it does. Either the plugin documentation is incomplete or I'm missing something...

2. In one of the runs I made when testing the new workflow structure, the contract deployment script did not mint the expected amount of T (minted 0.0 T). Here is the run: https://github.com/threshold-network/solidity-contracts/runs/7560768157?check_suite_focus=true.
   I also had similar situation with NU (minted 0.0 NU) in another run:https://github.com/threshold-network/solidity-contracts/runs/7556698468?check_suite_focus=true.
   Most of the runs minted correct amounts of tokens.

[michalinacienciala]

I tested the deployment again, this time on a branch being combination of changes from #119 and #118 (+ some small changes in workflows to allow for testing). Deployment has failed due to an issue in one of the modified deployment scripts, which I described in https://github.com/threshold-network/solidity-contracts/pull/118/files#r943208193.
The #119 can reviewed, but we will not be able to publish the package until the problem with failing deployment script gets fixed.

[michalinacienciala]

The #119 can reviewed, but we will not be able to publish the package until the problem with failing deployment script gets fixed.

The problem with the deployment script got fixed. I verified the #118 + #119 again, works as expected. Workflow run: https://github.com/threshold-network/solidity-contracts/runs/7801852357?check_suite_focus=true.

[nkuba]

I'm wondering whether common parts of contracts-deployment-testnet and contracts-dapp-development-deployment-testnet could be extracted to a reusable workflow or action. But this is something that could be handled in a follow-up PR.

[michalinacienciala]

Definitely something we could do! There's more places in our workflows where using custom actions or reusable workflows could be useful. Let's not wait for these improvements to not postpone the merge. I will refactor the workflow in the future.