[DEVX BUG] foundry's expectRevert behaves unexpectedly with SuperTokenV1Library

[d10r]

Problem: when using the SuperTokenV1Library in foundry test cases, something like may not work as expected:

vm.expectRevert();
// say the sender has no tokens and this shall revert
superToken.createFlow(alice, someFlowRate);

In case this is the first state-modifying call of a lib function, it will trigger the lib-internal address caching, which uses low-level calls.
In that case the revert isn't properly bubbled up, see foundry-rs/foundry#3901

The result is that the test case will fail, with foundry claiming that an expected revert didn't happen, although it did.

Currently this can be mitigated by doing an arbitrary state changing call, e.g. superToken.increaseFlowRateAllowance(), beforehand.
But that's an ugly hack.

What we can do:
Add a dedicated function for cache warmup, e.g. _warmupCache() and use it in our example code.

[0xdavinchee]

this was previously addressed and removed, see comments: #1428

[d10r]

I see