feat: add NonceTracker contract

[shrugs]

🚀 Description

/**
 * @title NonceTracker
 * @author Matt Condon (@shrugs)
 * @dev A simple way to keep track of nonces and restrict access.
 * Use the `withAccess` modifier to restrict access by address.
 * Use the `withMaxAccess` modifier to restrict access by address up to a max amount
 * For example, withMaxAccess(msg.sender, 1) will only allow once-per-address.
 * You can also accept nonces from users (as part of a hash you verify).
 */

[shrugs]

I want to refactor this to use the AutoIncrementing library. Depends on #1023

[shrugs]

Actually, after trying to refactor, I'm not convinced it benefits from using AutoIncrementing at all. @frangio I see you gave a 👍 ; any thoughts?

[nventuro]

Technically, it reverts 😛

[nventuro]

Shouldn't this be called NonceTrackerMock, for consistency with the rest of the directory?

[shrugs]

the pattern I've been using for mock/impl is mock == use a fully-functional implementation, but make it more accessible for testing. implementation == implement some other thing in a way that a real contract would.

but we haven't really followed that at all afaik, so ¯\_(ツ)_/¯

[nventuro]

Haha I see. I'll take a look at making them consistent in the near future then.

[nventuro]

What's the _nonce value supposed to be here? I'm not really sure what the intended usage of this modifier is (there are no docs for it btw).

[shrugs]

I will add docs :)

But it's intended to "register" your usage of some resource, given a specific nonce. For example, using Bouncer, you would pass a custom nonce to avoid replay attacks and invalidate previous signatures. NonceTracker keeps track of the latest nonces and enforces that they only increase

[nventuro]

Oh I get it now. A bit convoluted though, isn't it? Since you're free to pass any nonce you wish, I don't really see a use for this other than the Bouncer. It's also wildly different from withMaxAccess (and incompatible, using one in a contract will break the other), to the point where I'm not sure if it shouldn't be its own thing (a Bouncer extension to prevent replaying txs).

[nventuro]

We're using require as of #1074 :)

[nventuro]

I see what you're doing here with the test cases following a sequence to prevent code duplication, but I'd rather them be a bit longer and independent - fragile test suites are always a PITA.

[nventuro]

I take it you intended to use AutoIncrementing for WithMaxAccess? What didn't you like about that approach?

[shrugs]

Mostly because AutoIncrementing doesn't (shouldn't?) support manually setting the previous id. It's designed for incrementing ids of things, not tracking nonces. So to support nonce tracking it'd have to have a setter for manually setting the prevId field and now we're sort of breaking minimum concerns.

[nventuro]

Agreed, but it'd work if we restricted this to us the withMaxAccess modifier, right? Though at that point I'd call this by some other name, since it's not really doing nonce tracking but call amount restriction.

[shrugs]

I think it's necessary to allow arbitrary nonce submissions, since incrementing won't always be done on-chain (like when using the bouncer pattern; I want to be able to invalidate previous nonces by signing a new nonce and submitting that on-chain).

[shrugs]

closing as part of #1272