Assess if it's even worth keeping legacy ABI/protocol sequence in clrfund contracts.

[daodesigner]

So I just finished reading though all the V1 contracts, writing up initial thoughts in pseudo code as to the order things happen in before/after at a high level. MACI 1.0 is (understandably) a breaking change and I think our team is currently underestimating the downstream impacts, given the already hacked together contracts used in clrfund and changes to MACI internally.

• Read through all V1 contracts.
• Rough out new Protocol Sequence
• Determine Technical Debt vs TTM

[daodesigner]

Pseudo code (mostly to keep track for my own notes using handwavy Solidity Inheritance)
Currently we do :

Deploy MACIFactory(libs, params, etc)  --> 
Deploy FundingRoundFactory(MACI Factory, registries, config, ...) --> 
Method FundingRoundFactory.deployFundingRound {
               Deploys MaciContract(registries, config, ...)
               Deploys FundingRoundContract(MACIContract, ...) 
}  --> 
New FundingRound Contract {
               Implicitly maps MACI Vote options to Recipient Registry Ids which are indexed as an increasing integer sequence
               Calculates Initial Voice Credits via hard coded method
               Makes calls to MACI signup to give voice credits (does MACI signup on contribution if allowed by registry)
               Makes calls to MACI when user votes (does MACI publishMessage on submitMessageBatch) 
               Calculates Donation as:  matchingPoolSize * _tallyResult / totalVotes + _spent * voiceCreditFactor
               Allows anyone to pull payments to recipientRegistry[_voteOptionIndex] given valid proof as input
}

now we can do:

Deploy ConcreteImplementation is QuadraticFunding is MACI ( proxyInstance, SignUpGatekeeper  InitialVoiceCreditProxy, RecipientSignUpGatekeeper, MACIConfig)  --> 
New ConcreteImplementation Contract {
               Makes calls to MACI signup once for Contributors on signUp method
               Calculates Initial Voice Credits through InitialVoiceCreditProxy on signUp
               Tracks the current Quadratic Funding Round (maps round #--> FundingRound --> Poll )
               Increases/Resets Voice Credit balance on contribution each round (other wise have to sign up again each round anyway) //think we call this "top-ups?"
} --> 
Method QuadraticFunding.newMACIRound {
               messageAqFactory.deploy(...) --> New AccQueue
               pollFactory.deploy(AccQueue) --> New Poll (AccQueue)
               deploy FundingRound(Poll, ERC20Token, SignUpGatekeeper, RecipientSignUpGatekeeper, coordinator)
} --> 
New FundingRound Contract {
               Implicitly maps Poll Vote options to Recipient Registry Ids which are indexed as an increasing integer sequence
               Makes calls to MACI* indirectly via Poll when user votes (does calls to  AccQueue on Poll.publishMessage) 
               Calculates Donation as:  matchingPoolSize * _tallyResult / totalVotes + _spent * voiceCreditFactor
               Allows anyone to pull payments to recipientRegistry[_voteOptionIndex] given valid proof as input
}

[daodesigner]

completed napkin implementation