OC + AP payments contract

[maurolacy]

Closes #491.

Publishing as Draft for early review.

TODO:

• Send the rest of the funds to the tg4-engagement contract for distribution. (done)
• Don't pay if not enough funds for all members (prioritises engagement point holders). (done)
• Complete missing payments since last payment? (no)
• Queries.
  • Config. (done)
  • Payments. (done)
• Unit-tests. (done)
  • Basic init. (done)
  • Happy path. (done)
  • No funds -> nothing happens. (done)
  • Not enough funds -> pay engagement only. (done)
  • Pay twice test -> nothing happens. (done)
  • Try to pay after hours -> nothing happens. (done)
  • Empty OC / AP members. (done)
• Update Admin / UpdateConfig (through proposal?) ([tgrade-tc-payments] Add UpdateAdmin and UpdateConfig entry points #496).

[hashedone]

In general - I don't see any problems with code, but I don't like tests (very literal and difficult to read IMHO), and I am not sure about the batch sending approach. I get that cw2222 does not apply here (but being perfectly honest - it would work without major changes), but it can be simplified and perfectly applicable here. For my approval, I have to wait on someone's opinion at least for this batch looping to be confident.

[ethanfrey]

Interesting use of real dates.

I am also a little hesitant of these batch queries and pushing out potentially 100s of messages. At some point, the message JSON will be more than 256kB and the VM will reject it (consider it an attack vector).

But... this should work fine up to 100 or 200 members in OC and AP combined. It may end up as 1s or so then, maybe 2s. But it is amortised over a whole day/month.

Also, there is no real attack vector to add infinite number of these accounts to slow the chain. If you can control the majority of the OC, you can do much worse things already. Maybe you gain the majority of the AP and then add 10.000 new members to clog up the blockchain??? Very unlikely and since this is not some permissionless entry point, I find it safe enough.

That said, I do see room for improvement/optimization, which should be tracked in an issue, but this is good enough as is for mainnet launch.