improve(tests): silence unsafeAllowDelegatecall warning in tests

[bmzig]

Applies the function introduced by OZ in this PR: OpenZeppelin/openzeppelin-upgrades#228. This is only used on two test fixtures, so we still should see warnings when we deploy.

[james-a-morris]

OOC will this potentially silence other warnings?

[bmzig]

OOC will this potentially silence other warnings?

It would if there were other warnings thrown in those fixtures.

[nicholaspai]

fixtures by design are only used in tests so this is nice. Is there way to target specific warnings?

[bmzig]

fixtures by design are only used in tests so this is nice. Is there way to target specific warnings?

I don't see a way to do this. I was referencing this post: https://forum.openzeppelin.com/t/logging-verbose-during-local-tests-with-upgradeable-contracts/4633, which seemed to have similar issues as ours. I changed this to just instead silence warnings for our contract tests only. The upside is that we should have a clean output for our tests, but the downside is that any warnings emitted from @openzeppelin/hardhat-upgrades will be silenced (e.g. the unsafeAllow options found here) I think this is OK, since we still will need to explicitly supply the unsafeAllow type when deploying the contract.

Edit: I'm reverting this change and going to back to what I originally had since if we don't suppress the warnings in the fixtures, then we will get spammed in the other repositories, e.g. the relayer.

[socket-security]

No dependency changes detected. Learn more about Socket for GitHub ↗︎

👍 No dependency changes detected in pull request

[james-a-morris]

Curious about Nick's comment. This is what I was probing at. If we can't and this looks good I will approve so that I'm not a blocker

[bmzig]

I reverted the package bump since this I don't think this is significant enough to merit a version change. We can just include it whenever we need to upgrade contracts. This should stop the spamming in the relayer repository's unit tests.

As far as silencing specific warnings, I don't think this is possible, but it shouldn't matter, since we know that the warnings will only be emitted if we have an unsafeAllow option somewhere in the code. Essentially, we need to already acknowledge and mark that the warning is allowed in the contract for it to be silenced.