for any auto top up

In case language_id guessed wrong

* multi-account-billing:
  Use billing customer for LowBalance notification
  Get settled amount from billing customer for TrustLevelRepo
  Use the multi account billing schema

* voicemail-on-error:
  Use default OGM when error loading customer
  On customer load error, try not loading from SGX and assuming no transcription

* admin-actions:
  Admin Command Flash
  AddInvites Command
  SetTrustLevel Command
  ResetDeclines Command
  Undo and Undoable Command Harness
  Move Cancel and Financial Admin Commands
  AdminAction and AdminActionRepo
  Invites Repo
  Cleanup Admin Form

Having a second response here just to show the result, and then have to
skip by it to get back to the menu is dumb.

So instead we just added a thing here so we can tag some info to show up
on the next form, and then go to it.

Much smoother, but it does depend on a change in the adhoc bot which
previously didn't show notes when there was also a form.

This one adds a certain number of invites to a user, and then records
which ones were added so they can be removed in the undo case.

Here we have a form for the extra information we need. They say they
want to set the trust level, we ask which one they'd like, and then we
make the command that does that.

This involves adding a new method to the TrustLevel to get just the
manual level, so I can tell the difference between being set to Customer
manually (in the form) or being automatically determined to be Customer
(which means the form should be set to automatic).

I also obviously need the method to set a new trust level too.

This is a nice simple first one.
I set the declines to 0, and on Undo I set it back to what it was
before.

There's no extra form or information, it just does the thing.

It's a little weird to start with Undo when there's nothing to Undo yet,
but it's laying the groundwork for what's to come.

This gives me a harness I can use here that gets the action, performs
it, gets the result of that performed action, and then persists that to
the log and reports success or failure.

And the first such action I have just grabs the most recent item and
undoes it.

This class gets pretty tight later, so I have to move these out to make
room in the class for the other commands.

This Simple class is a bit weird on its own here, but it makes a bit
more sense later when compared to another class.

This allows me to enqueue a description of a change to a stream and then
run it. And then later find / list them and undo any of them.

The goal here is to make these safe to run and safe to reverse so the
user can just run things with confidence knowing that undo's always got
their back.

This allows me to avoid confirmation boxes on everything and careful
scrutinizing of each command before it's run just in case...

In preparation for another command I'd like to make I've first got to
make a place where Invites live.

There's probably other parts of the code that interact with Invites that
I've missed, but this is a good start at least.

It used to handle the initial failure differently than internal failure.
Now I've moved the outside bits inside, so it can run again when it
encounters an unknown character.

* policy:
  Show FUP before starting registration in earnest

Disabling the Bandwidth transcription in the process

So that singletons can be added, for example

Explicitly return true to avoid passing to next link in the tree.  Make sure
command stanzas fulfill both command and iq manager if needed.

* dry-sentry:
  DRY up sentry and logging

* vcard4:
  Switch TTS OGM from vcard-temp to vcard4 PEP

Wrap every blather handler in sentry setup and exception capturing so each route
doesn't have to handle it seperately.

panic is a last resort, usually better to return an XMPP error and report/log,
so default to that.

Also wraps each handler in a span. Note that for multistage command handlers
this span is too long and they will want to call finish/set_span internally.

* background-log:
  Log in background thread
  Don't run our whole app in an at_exit

File IO is fast, but can still block reactor.

We don't use much of it, and this makes using other at_exit hooks more realistic.

* new-blather:
  Update to latest blather upstream
  notify_customer helper

See: https://github.com/minitest/minitest/issues/912

Which has merged our changes

Makes the number of users to do on startup much smaller and slower-growing.
Expired users have been told about their low balance quite a bit already, and
will be notified by billing cronjob etc from here out.

The bitfield bit 1 was used by a different project (sgx-catapult, see:
https://gitlab.com/ossguy/sgx-catapult/-/commit/459d7d1dfe208db1708f1d648b82b38c002ad35a).
This other project no longer uses the bit, and in fact that whole project is
dead and gone, but if you previously ran that project against the same redis
that you now run this project against then please make sure you have zeroed-out
that bit first.

You can verify using this script:

    redis = Redis.new
    redis.keys("catapult_settings_flags-*").each do |k|
      p redis.getbit(k, 1)
    end