Block users who get too many card declines

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.
Prevent double-activate

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.
Log plan name on exception to sentry
Allow activating an account via credit card on web

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.
Higher XMPP connect timeout

Because sometimes the box is under high load.
better healthcheck log
Don't notify when re-processing transaction already in DB
Initial test suite and helpers
Send complete, useful approval message on account activation

With link pointing to jmp-register until new-signup happens.
Switch to stepwise bonus factor breakpoints

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.
Send notifications using Cheogram whispers

This way they don't need an assigned tel to work.
Include BTC amount and currency in notification
Don't send malformed to JID when customer has no tel yet
Ping healthchecks for each run
Activate pending plan for customer when they pay enough BTC

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.
Add bonus whenever a larger BTC deposit comes in
Notify customer on sucessful BTC deposit

Since BTC transactions can take some time, let the user know when it is done and
how much credit they got for their money.
Notify customer when renewal fails due to low balance

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

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.