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

* snikket:
  Initial bare-bones admin command for launching a snikket instance

* limit-credit-card-amount:
  Limit size of credit card transaction by trust level

* limit-top-up-take-2:
  Only one credit card transaction per customer per day

This reverts commit 7a28753d7df5d7d6f5f890d302634b1bdbd25f73, reversing
changes made to e4ec9b8eb368ed0997887ebd99f8c79982640d20.

* limit-top-up-freq:
  Only allow one credit card transaction per customer per day

* cancel-account:
  Admin command to cancel customer
  Move Customer factory/extractor to Customer

Notify customer
Deregister from SGX
Deregister from Cheogram
Disconnect from Bandwidth
	If on special list, move intead of disconnect

The repo's job is to get the data, constructing the object can be a factory's job.

* more-admin-info:
  Test Admin Info with Numbers
  Refetch Customer on Repeated Customer Info Calls
  Trust Level in Customer Info
  Show Callability State in Customer Info
  PromiseHash
  No Settled Transactions is 0, not Null

My current two AdminInfo tests have unregistered customers because it's
easier, but it means that some parts of the logic don't get tested.

This one digs a bit deeper to test this part of the forms, but it
requires injecting a repo

This means if I fetch a user, make a change (add a transaction, set
their trust level, etc), I can re-run info from the menu to get the same
user with up-to-date info, so you can see the thing I just did reflected
back to me.

We have this thing, so we should probably be able to see it

This shows relatively easily which class a given user finds themselves
in.

Whether they can't call because they have no balance, or if they have
lots of room, or if they're being asked.

Hopefully this will make it easier to tell at a glance if a calling
issue is due to a few things.

Here in info I'm doing a lot of this pattern:

    EMPromise.all([one, two three]).then { |one, two, three|
    	new(one: one, two: two, three: three)
    }

Which felt really noisy for what is a pretty logical operation.
So now I can keep the keys and values together and do:

    PromiseHash.all(one: one, two: two, three:three).then(&method(:new))

It's smaller, but more importantly it's more meaningful to me.
It keeps the declaration of the meaning together with the sourcing of
the value.
And because it uses EMPromise.all in the guts it's not a problem if some
of the keys are not promises.
Easy-peasy!

Unexpectedly this doesn't return either no columns or a column with a
value of 0, but instead a column with no value...

* message-limits:
  Block outgoing messages when expired
  Contacting support is not billable
  Use TrustLevel to determine daily quota
  Refactor message limits, change to 500/day

This allows a customer to change their JID, but it's a bit raw.
In practice I don't expect anyone to actually run this directly, instead
cheogram covers with with a friendlier and safer version.

This is just the business.

* block-calls-when-expired:
  Block voice calls when account is expired
  Refactor CallAttempt factory to use registration pattern

This reverts commit 36f441c031a5318385ec78d7d2e021a8e2fab186, reversing
changes made to 3b0ae3c9387d3be41b30bd6dd4552ff0a841d8ed.

* three_d_secure:
  Send 3DS id when making a transaction

Allow for "transitional" (no plan) users for now, because we still have a bunch
of those.

* change-billing-lock:
  ExpiringLock instead of require expired
  Atomic ExpiringLock

We *want* to try billing a little before expiry, to prevent the account lapsing.
So use an ExpiringLock to prevent double-billing races.