allow participants to be created during payday

[chadwhitacre]

Gittip 7 failed and had to be re-run after repairing the database, because of corruption that was introduced when two participant records where created while Gittip 6 was in-process. See #169 for details. This ticket is to fix the underlying problem, and should obviously be addressed before Gittip 8.

The first fix is to put a NOT NULL constraint on balance (see #35, and rue the day), so we would catch this the week it first happened instead of the next week.

The second fix is to add a WHERE pending IS NOT NULL clause to the update where this broke down:

        UPDATE participants
           SET balance = (balance + pending)
             , pending = NULL
         WHERE pending IS NOT NULL

That will ensure that participants created after payday starts are not clobbered at the end of payday.

We then need to tweak the queries at the start of payday to guarantee that any participants that were created after the start of payday will not be included in the list of participants to include in this payday, should we need to rerun it. That means adding WHERE ctime < ts_start clauses on the queries that zero out the pending column and fetch the list of participants for payday.

Of course now that we have a test suite for billing (#44) we should also write a test for this before fixing.

Here's another question: What happens if someone who signed up before payday tips an account that's created during payday? I believe we need to take steps to prevent against that as well.

[chadwhitacre]

Survived this for Gittip 10.

[chadwhitacre]

First run with this is Gittip 18 (#319).