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.

For use from Asterisk

There is an edge case where a customer might not have auto-topped up yet but
they don't have enough balance for this call, so try to charge their card first
before telling them the call is a no go.

If cannot find an acceptable rate for the number, cannot call.
If balance is too low, cannot call.
If too close to limit, warn.
Else, call.

This will allow us to switch asterisk to the new logic before rolling out the
limits.  Asterisk will then support the limits once sgx-jmp begins instructing
it about them.

Introduce objects representing the different kind of query keys that can be used
to look up a customer.  These keys know how to use themselves to get
the (customer_id, jid) pair that is needed for an actual repo lookup.  All
find_by_* methods are now just trivial wrappers over these objects that pass on
to find_inner.

This enables the easy creation of a new helper: QueryKey.for, used as
find_by_format which allows passing an xmpp: URI, or a properly formatted tel,
or a customer id, and will find by the correct one.  This could cause a problem
if a customer id were to be a valid xmpp: URI or a formatted tel, so this method
does assume not using these formats for any customer id (which would be
ill-advised in any case).

Generic error message to contact support.  No current customer will hit this
limit based on historical usage.

We've started getting lax about vetting the warnings because there are too many.
Raise the threshold for a warning.

This is based on a hotfix in prod. In this case someone appeared to have
talked to an @jmp.chat address directly. In normal circumstances this
shouldn't happen, but it's not technically disallowed, so we probably
shouldn't just crash.

In case you've been living under a rock and don't know what an eTransfer is.

This is certainly an accidental holdover from the original code, and was making
voicemail from anon not work at all.

Will suppress bogus messages transcribed from silence or a click, and in
general getting a transciption without getting a recording is just odd.  If we
decided the recording is not worth sending, the transcript certainly isn't.

By default bandwidth includes numbers in the "local calling area" of a search.
This is confusing, so change it to include only actual matches.

* overage-limit:
  auto_top_up_amount and monthly_overage_limit from CustomerRepo
  Move Bandwidth Tn remote operations to BandwidthTnRepo
  Use value_semantics to DRY up CustomerRepo
  Use NotFound exception for all customer not found cases

Move load of auto_top_up_amount to the repo, and load monthly_overage_limit in
the same operation.

* nuke-legacy-customers:
  Remove LegacyCustomer

Such customers are not longer a common or valid case.

There's a bit extra info I wanted about users, so since I was doing this
anyway I figured I may as well port the existing forms to the new form
renderer.

Then, in order to fit within the guidelines I needed subforms, so
partials were added.

We were setting in one property but reading from another very similar
property...