fix: Coupon mintlist system

[JamesEarle]

This change creates a mintlist system based on a verified signer we control having signed off on each "coupon" that an account can use in registration of a subdomain. If the user presents a message that was not signed by our dedicated coupon signer (TBD what account this is) then it is not considered a valid claim.

What still needs to happen

• changes to the deployment campaign so the EIP712Helper contract is set properly
• Decision on what account we use as a signer

Considerations:

• Using this system relies on the assumption that we first get the owner of a domain to sign a message stating that they allow our coupon signer to sign messages on their behalf. Once we've collected this signature, we can create the data they've provided.
• There is some deciding to do around what the unique data is in each coupon. We can use the domain label as an intrinsically unique piece of data but there is question about how that might be considered forceful by an owner, allowing a specific user to only mint a specific domain, and so alternatives could be some unique ID but this requires we keep track of what has been used on chain in some mapping
• Tooling around how we create this data is still to be determined. They could upload a JSON file of addresses, or fill a web form, etc. and we have to intake that data and transform it into proper coupons structured as below

// typescript
type Coupon = {
 parentHash : string;
 registrantAddress : string;
 subdomainLabel : string;
}


// solidity
struct Coupon {
 bytes32 parentHash;
 address registrantAddress
 string domainLabel;
}

[openzeppelin-code]

fix: Coupon mintlist system

Generated at commit: 1132ff952346b4d67d6e88edb998cf38e535580d

🚨 Report Summary

	Severity Level	Results
Contracts	Critical High Medium Low Note Total	0 0 0 5 25 30
Dependencies	Critical High Medium Low Note Total	0 0 0 2 29 31

---

For more details view the full report in OpenZeppelin Code Inspector

[codecov]

Codecov Report

Merging #101 (1132ff9) into development (8f67434) will increase coverage by 0.00%.
Report is 2 commits behind head on development.
The diff coverage is 100.00%.

Additional details and impacted files

@@             Coverage Diff              @@
##           development     #101   +/-   ##
============================================
  Coverage        99.80%   99.80%           
============================================
  Files               11       12    +1     
  Lines              512      514    +2     
  Branches           127      128    +1     
============================================
+ Hits               511      513    +2     
  Misses               1        1           

[Whytecrowe]

can this be a pure function?

[Whytecrowe]

yeah, this should be a state var.