* bill-with-note:
  Add a note when billing account

* activate-with-balance:
  If customer already has enough balance, just bill them and finish
  New BillPay registration step
  Save plan to DB as soon as it is selected
  Move credit_to lookup into relevant class

Assumes they have enough balance (anyone using this step must be sure of this)
and then does the billing before proceeding to finish.

Customer will appear as instantly expired (having been active for 1 second in
the immediate past).

This can replace the pending_plan key for BTC activations. It also serves as a
record for mail-in activation of what plan they had selected.

Once the account is really activated the tiny row is removed.

* monthly-billing:
  Allow the DB to notify us to bill a customer
  Command.execution setter
  Bill plan command
  Clearer name for lock bypass factory

Implements the full logic of the billing_monthly_cronjob for one customer by
reusing code that has been written more robustly in sgx-jmp for some time.  This
will allow the cronjob to just execute this command once a day for each expiring
customer to get all the correct billing behaviours.

Previously this retured a string and everywhere that used it had to
convert it into an it, or handle it if it's nil.

That's dumb.
Now it's always an int, and `nil.to_i` is 0 anyway so I don't have to
check that either.

In my testing the natural order just happened to be the date order
because I had so little data.

But in the real world we should probably be more explicit!

Since this is used by the billing cronjob and hitting BW so much is too expensive.

Previously cancels would be treated as an error, but then would be
caught so that they could respond with receipt of the cancel later.

But, we weren't setting @iq in these cases, because it was an error, so
we would actually respond to the wrong stanza; specifically the one
before the cancel.

This was bad and wrong and led to the bot sitting there waiting for the
cancel before moving on with its life.

We don't always use this to get the current user, so make it optional.

Not only is it allowed, but actually there's a ton of empty notes. Every
monthly account activation is missing a note, so practically every user
that has transactions will have empty notes.

Some automated processes don't care for our menu, and rather than
crashing it should just consider our process to be done.

* tx-list:
  Admin Command Menu + Admin Financial View
  Transactions List
  Customer Financials
  Telephone Link

I've added a new command to show financial information about the user.
But more importantly I've added an infinite admin subsystem which allows
me to go into a user and then run multiple commands on them.

For now it's just these two info commands, but in the future I'd like to
add mutative commands here.

Finally, since I sometimes look up multiple users in a pretty short
timeframe I made the menu open and if I put something into the list that
doesn't parse as one of the actions it instead switches the current user
so I don't have to do "cancel", "customer", and then put the next one
in.

I can just have the session open and put stuff in as needed.

Using the new Financials object a user can list their transaction list
We only show the user the date, amount, and method.

I've pulled out information about payment methods and bitcoin into its
own thing. It's kind of a repository, except that it only exposes
fetchers and doesn't load anything generally.

There's also a few new methods here that aren't used yet, but will be
shortly.

Sometimes I need to go there to look something up or change a setting,
and every time I do I have to navigate through the UI to a number I
already know.

This should make that faster.

* state-search:
  Finish state search and add test
  Add state search - for granularity & jmp-register

Note that this is not quite complete yet, since we need to pull in the
STATE_MAP stuff used elsewhere to make it work properly.  But it will
at least work for every state/province/territory that is not Quebec
for now, which is way better than nothing.  Quebec users will get the
same fallbacks they had before.

If the SGX fetch fails, this is a problem.  Even in the original case this was
written for (registration) we have seen strange issues that can come up when the
code assumes that an SGX error means they are unregistered.  They may or may not
be unregistered, and we simply don't know.  So we should let the error bubble
through and be handled (if possible) upstream.

The to in leg2 is not the phone number, but the fwd, which is not useful for
looking up customer.

Doesn't affect any current code paths, but should be correct in case we ever
start using it in the inbound case.

Also from does not have to be a formatted phone number, can be a string like
Anonymous, etc.