* 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.

* only-bill-if-expired:
  Only bill customer if they for sure have balance and are expired
  Allow an in-transaction condition for billing
  Change multiline chain style

* sip-concurrency:
  Limit call concurrency for outbound SIP

* fwd-cleanup:
  Try to classify URI before saving, even if timeout.zero?
  v1 is dead and everyone has been moved
  Allow finishing adming command

To allow building from a hash with extra keys. Makes the CustomerRepo more readable.

Helper for queries that only return a single row.

* max-call-length:
  Calculate the maximum allowable call length

* credit-card-blacklist:
  Credit card blacklist

Any card on the list is just treated as though it is not present, preventing it
from being used.

Asterisk could use this to actually limit the call, for example.

* trustlevel-repo:
  TrustLevel{,Repo}

To determine how much permission a customer account should have to take risky
actions.  Seperate from their plan, this is not how much they could do in
theory, but how much the system will allow in practise due to perceived risk.

Starts out with a simple model based on amount of settled payments, and being
used to decide what is an "expensive" route for outbound calls.