getSigners behavior can be error-prone

[fvictorio]

According to @nventuro, the fact that the first account returned by getSigners is the default signer is error-prone, because you need to remember to omit it in tests that involve accounts that are not the one that deployed the contracts. In other words, cases where this:

const [admin, other] = await ethers.getSigners()

is a mistake, and you actually want to do:

const [, admin, other] = await ethers.getSigners()

Possible solutions are:

1. Change the behavior of getSigners. This is a huge breaking change.
2. Add a parameter to getSigners, so that you can do getSigners(1). This seems like a no-solution, because you still have to remember to pass that value all the time. Plus it's ugly.
3. Add a new method (getNonDefaultSigners or getTestSigners or getOtherSigners or whatever). Here you still need to remember to use the right method, but that can be enforced by a linter rule.

The problem with the third option is that we don't want to keep adding methods to the ethers object, because it's very confusing for users who don't understand the difference between ethers itself and our monkey-patched version.

[nventuro]

Indeed, this is why @frangio and I decided to drop the first account in OZ Test Environment and make the notion of a 'default sender' more explicit.

The argument goes that a) any transction in which the sender is relevant should have an explicit sender, and b) all senders defined when destructuring getSigners() are relevant. This results in the need for it to be impossible to implicitly use a relevant sender: the easiest way to achieve this is to prevent the default one from being relevant by not having it be part of the sender array.

Changing getSigners is not only a breaking change but also undesirable: in non-testing context you likely do want to be able to access all unlocked accounts. I think adding a new method is fine, as mentioned linting (or opinionated warnings) can help direct the user to this suggested usage.

Re. monkey-patching, does it have to be a method in ethers? Can't it be a standalone function?

[fvictorio]

Re. monkey-patching, does it have to be a method in ethers? Can't it be a standalone function?

This function would need access to the runtime environment, so it would need to receive the hre as a parameter... unless it's just part of its closure. We haven't figured out yet how we want to tackle the problem of exposing helpers like these without the monkey-patching, tbh.