feat: localhost and hardhat deploy can be run with zero config

[jordaniza]

Description

Currently, running the deploy script requires several steps and env var config. Default values are suggested in the README so this PR uses the default values as fallbacks when the network is localhost or hardhat.

Implementing this properly required:

1. Creating the fallback values as functions in a helper file in the utils folder, and adding a quick set of tests.
2. Replacing calls to process.env with the fallback functions.
3. Adding a pre-deploy environment check to prevent script execution in a live environment, if the env vars are not set (this is extensible for the future)
4. Some changes to the README to reflect the code changes, along with some utility commands in package.json
5. Some changes to hardhat.config to setup the localhost runner.

Task ID: OS-1040

Type of change

• New feature (non-breaking change which adds functionality)

Checklist:

• I have selected the correct base branch.
• I have performed a self-review of my own code.
• I have commented my code, particularly in hard-to-understand areas.
• My changes generate no new warnings.
• Any dependent changes have been merged and published in downstream modules.
• I ran all tests with success and extended them if necessary.
• I have updated the CHANGELOG.md file in the root folder.
• I have updated the DEPLOYMENT_CHECKLIST file in the root folder.
• I have updated the UPDATE_CHECKLIST file in the root folder.

[heueristik]

What are the implications of using a random address here?

Instead of a random address, we could think about using the known hardhat default address (derived from hardhat's default mnemonic 'test test test test test test test test test test test junk'.
I think it is 0xf39Fd6e51aad88F6F4ce6aB8827279cffFb92266.

This could result in tests passing (that mostly use signers[0]), although this could be equally undesirable.

[jordaniza]

We already use the private key for the HH address you listed as default. So possibly we can use the next derived address from that same mnemonic.

[heueristik]

Yes, sounds good. Maybe for the default, we can have two or three approvers (and a 1/2 or 2/3 threshold) - all from the default mnemonic.

I am wondering how this will work in combination with local fork tests.
In the future, we might want to do similar fork testing like I did it for the osx-plugin-template-hardhat.
I guess we can adapt these functions once we decide to work on this.

[jordaniza]

I think adding multiple approvers is a good improvement that should be added to the backlog for fork tests. I would avoid changing that inside this PR

[heueristik]

Agreed, can you add a task and link it here?

[heueristik]

See my comment above https://github.com/aragon/osx/pull/539/files#r1489567374

[heueristik]

Let's double-check that there is no scenario, in which a wrong list of approvers can be set accidentally (see my comment about || [deployer].

In production, we should throw errors if env variables are not set, which we do in the script tagged 'Env' check. However, you can select/exclude certain tags which could result in the 00-env-check.ts not being run.
In this case, the script must throw an error too and not silently run with a wrong approver list.
Let's make sure that this is the case

[jordaniza]

Let's double-check that there is no scenario, in which a wrong list of approvers can be set accidentally (see my comment about || [deployer].

In production, we should throw errors if env variables are not set, which we do in the script tagged 'Env' check. However, you can select/exclude certain tags which could result in the 00-env-check.ts not being run. In this case, the script must throw an error too and not silently run with a wrong approver list. Let's make sure that this is the case

Yeah so any time one of the XXXenv functions is called, it throws internally if:

• We are on a real network
• The required env variable is not set

In this way, the Env check is a redundancy but also helps to signpost all the required variables before any transactions run. If the required env variable is not set and a deploy script is run, we will still throw when the variable is accessed with a helpful error message.