The craziest part of this is the workaround for a serious bug in Bandwidth's
HTTP voice API (which they may yet fix, still negotiating with them about that).

When a call comes in, every 10 seconds that it is not "answered" the inbound
call gets cancelled by their upstream peer and then get retried.  The caller
sees only one oubound call for this, so it doesn't look odd to them, but to us
it looks like they keep hanging up and trying again every 10 seconds.  So what
we do for now is we wait 2 seconds after they disconnect before we decide
they're really gone.  If they call back in those 2 seconds we just connect the
eventual bridge or voicemail to this new call and everything works out.

Ew.

* number-search:
  Do not direct back to website to pick new number
  Run rubocop after tests
  Add reference to option to show where the tel is
  Format tel for human reader
  Allow user to search for numbers over XMPP
  s/WebRegisterManager/TelSelections

Instead, if number is no longer available keep them in flow and use the number
search tool.

* finish-btc:
  No more legacy session for BTC
  Do not lose WebRegisterManager on retart

Set the same key as web register manager, so that on next register jmp.chat the
tel we were using in this flow will be used.   Not needed if they came from web
register, but will still extend expiry in that case and no harm.

Clean up pending tel key on Finish.

Store web registrations in redis.  Set an expiry so they don't grow in RAM
forever as they previously would have without a restart.

We moved some of the currently private things to be public, like currency, and
then included things like how much the monthly price is as well.

Execute works, but next is more right

Turns out my dummy-sgx doesn't act the same as production.
Rather than getting a successful registration with no phone, in production I
get false, so I need to handle that.

And also so Gajim works

This should allow us, the admins, to query information about a customer
without having to dive in and run a couple redis queries and some
database queries before getting the full picture of who we're talking
to.

It also allows the users to request some data about themselves. Balance and
phone number are already visible in other places, but their expiry is currently
not, and people have been asking about it.

It turns out in newer versions of Ruby this isn't cool anymore.
The new way is BigDecimal(value), which is dumb, but whatever...

If we don't do this, the ad-hoc bot won't format the table properly.

* invite-codes:
  Command to list unused invite codes

Instructions also provide details about how the program works.

Don't fill redis with keys for users who did not go over

So we know very quickly why it's not working.

* low-balance-auto-top-up:
  Some people have exactly 5 who don't need to be told
  On low balance, top-up or notify
  ExpiringLock helper

On start up, check for users with low balance and NOTIFY about them.  LISTEN for
such notifications and process by either sending a low-balance warning message
or else attempting an auto-top-up as configured.

Using NOTIFY/LISTEN because then we can NOTIFY after any INSERT that leaves the
balance too low (using a trigger).  Doing the sync on start-up in case we missed
a NOTIFY during any downtime.  Using the Redis lock to prevent spamming a
low-balance user in case of many restarts or if they have many small
transactions happen in one day.

For things we want to do only so often, set up a helper to push expiring keys to
Redis and check for them.

* cancel-timeout:
  Timeout is not a fatal error
  When user cancels the command, respond with canceled

If the user does not proceed with a command after N time, we don't hold on to it
forever and time out.  We cannot return anything to the user because they
haven't sent us anything, so just ignore it.

If the cancel has not been fully handled in the body of the command, at least
respond with canceled status and do not go to sentry.