Support opt-out renewals (eip-1337)

[HardlyDifficult]

Is your feature request related to a problem? Please describe.
We are designing a system where people may purchase access rights for content, and those rights expire after a certain amount of time. This mechanism effectively offers an opt-in subscription model. For example, if the purchased time period was one month then in order to keep access 24-7 the user would need to manually re-purchase each month (this is what I mean with opt-in).

This model may not make much sense for users as they may think of this as a standard subscription. Outside of blockchain, users expect offerings like this to be opt-out vs opt-in (meaning the subscription auto-renews until canceled.)

This model may also increase revenue for content creators as their users may renew their key more frequently.

Describe the solution you'd like
EIP-1337 is a way of approving a subscription which can automatically be billed each month until canceled by the user. This requires a signed message approving the subscription to be stored off-chain. Some entity would monitor these off-chain messages and broadcast them on-chain when appropriate. Once broadcasted, the subscription is extended.

ethereum/EIPs#1337

Describe alternatives you've considered
n/a. I don't know if a similar idea has already been discussed.

Additional context
This only works if we bill in WETH, other ERC20 token, or require a deposit before hand. This is certainly a concern.

We could offer a small financial incentive to anyone who broadcasts valid renewals for a more decentralized solution, or the broadcasting could be done by Unlock or the Lock-owner directly.

Note that I'm not suggesting we replace any existing features. This could be an alternative way of purchasing Keys.

[androolloyd]

Interesting concept, I'd be curious if it could be made to work inside the current abilities of the specification.

It feel's as though it would just be an implementation, where the type of subscription comes into play, an opt in vs opt out mechanic.

[AnneJiang00]

Has anyone ever operated to cancel the subscription? Where should I cancel? Like gitcoin grants

[HardlyDifficult]

Goal:

• Sign a message authorizing purchase when their key has timeRemaining < x
  • Must include the _value as well to ensure they are not surprised by a keyPrice change (or the maxValue instead so they benefit from any keyPrice reductions)
  • Include a nonce to allow the user to invalidate the signature
  • Include a minimum expirationDuration so that if the Lock changes from monthly to daily the user isn't charged more than expected.
• Allow the user to cancel a subscription (by increasing the expected nonce). Removing ERC-20 approval is another way of effectively canceling the subscription.
• Allow the Lock creator to define a reward for broadcasting transactions (the reward must be <= keyPrice)

Support ERC-20 only (no ETH locks, for now at least). Ensure we bill the user which signed the message, not the msg.sender (like usual).

Questions:

• what's a good value for x? Maybe the user should specify this with the signed message.
• do we just leave _referrer and _data blank here? We could also let the transaction broadcaster to set those fields, or we could add this to the signed message. (i'm leaning towards let the broadcaster decide)
• do we share nonce with the cancel scenario? (i'm leaning towards yes)

[HardlyDifficult]

Implemented the feature with #5939