The config got updated, but the signature was missed.

We need to wait until all EventMachine items in flight are complete before we
allow the process to terminate or some of them might not happen.  So when the
process wants to exit, wait until the EM thread is done.  Use next_tick to make
sure our stop command only happens when the EM queue is next clear.

plan_log has been updated to use a range type, so our INSERTs need to be
updated as well.

We don't have auto top up built yet, but once we do they will be able to start
getting it right away instead of needing to manually turn it on later.

If there are no values to query with, then the SQL will be invalid and throw an
error, so just return empty for that case.

Found during initial migration, when a request comes in and it turns out there
are no new transactions, we should not try to set nothing to Redis since that
will throw an exception.

If a customer has > 2 card declines in 24 hours or an ip has > 4, then treat all
attempts as declines without looking as an anti-fraud measure.

We're seeing trouble in production where users activate more than once, which
results in suboptimal DB contents.  If they're already active, just redirect
them back to complete registration.

This is designed to work with current jmp-register flows pending new-register
existing.  Link a user to https://pay.jmp.chat/<jid>/activate?return_to=... and
they can choose to buy 5 months of service in either USD or CAD on a supported
credit card.  The card will be vaulted onto their newly-minted customer_id and
the amount immediately billed. No account balance will be set or used, but
rather a plan_log row created starting now and expiring in 5 months.

Because sometimes the box is under high load.

With link pointing to jmp-register until new-signup happens.

The max bonus is a bit smaller than the previous formula, but this one is
perhaps more "explainable" and still matches current pricing.  The breakpoints
are done in native currency (not currency-converted) which means that CAD users
get the next breakpoint "sooner" -- this is a small advantage to CAD users, who
we want to encourage anyway.

This way they don't need an assigned tel to work.

This is effectively the "BTC auto-accept" new way.  If they send enough to
activate (as set by activation_amount in config) and they have a pending plan in
redis and no plan in the db, then we buy them that plan.

We can't use the normal way to notify the user, because they likely haven't
bought a phone number yet.  Eventually we will be able to tell new-signup about
this and have it inserted into the flow there, I think? Not sure what we want to
do transitionally.

Since BTC transactions can take some time, let the user know when it is done and
how much credit they got for their money.

This is done by sending from a configured JID to <tel>@cheogram.com in order to
have them receive a message from support.

Renews all expired plans where there is enough balance to do so.

Sets expires_at on all renewed plans to one month from today, so even if they
were very expired they are up to date the moment they pay.

When they become confirmed, insert them into the transactions table.
We can never double-insert because of the PRIMARY KEY on transaction_id, so the
script is always safe to run even if something ends up in redis twice.

The intent is to use `electrum notify <address> <app>/electrum_noify?address=&customer_id=`

The app asks electrum for all transactions on that address, and then checks
which ones we *don't* already have recorded in the transactions table.  These
are pushed into Redis to be picked up by a to-be-written job that will write
them to the transactions table after 3 confirmations.

As a security measure, so people can't modify the cards on arbitrary JIDs.

So it's not really braintree specific, even if we make it match the one there.