Use the new with-amount jmp pay and when they click next check their balance
before we charge them, if they did make a transaction already then we can
proceed to BillPlan.

I use presence of only numerals to guess if a port is Canadian or not.
Today we got a Zip+4, which has a dash. Right... that...

Added columns to the eSIMs command to now display the nickname of a SIM,
if set.
Added test for the new columns in sim_repo.
Added nicknames column to sims form, and modified to a multiline form.

We get messages without bodies from time to time as things like delivery
receipts.

These are great, and we don't want to forward them to the end-user for
sure if we're dealing with a reachable number, but we also don't want to
count it as a message that reached us.

It's a receipt for a thing I did, not a thing the tester did.

This creates the keys that the previous commits use, and also reports
their current values.

It's a pretty sparse command in terms of UX, but only admins will use it
so I kept it simple.

This also optionally sends the prompt to one of the chosen reachability
numbers. It's optional so a human running the command can query the
result without looking in redis, but also without spamming their phone
with another message.

This intercepts calls that are from the reachability numbers and checks
their status.

I had to extend the reachability repo a bit because I realized that
unlike texts which I just want to do nothing when they're intercepted,
for calls I actually have to _return_ something in that case.

Due to my short-circuit none of the existing tests needed to be changed,
because the calls weren't coming from a reachability number. But then I
added two more tests, one to make sure a call from the reachability
number works normally if reachability is not being tested for that user,
and another that verifies that if we're testing reachability it hangs up
and increments the counter, which is the actual point of this patch.

On an inbound stanza it checks if the initiator is one of the
whitelisted numbers that can perform reachability checks. If not, which
virtually all received SMSs won't be, it just runs the code that was
already there.

If it is, then it does a further check to see if the reachability check
is ongoing for this user, and if not it runs the code that was already
there.

And finally, if the key exists it increments it and otherwise doesn't
process the message.

We made a change with the "direct_targets" that made it so support no
longer talks to phone numbers, but customer_blah@sgx.example.com

So, we no longer need to link to the phone number version of the jid,
but we now have this new one.

And while we're at it we also have a ticketing system that's based on
that same JID, so I'll make a link to that too.

* feature_flags:
  Put CDRs behind a feature flag
  Store feature flags on user for limiting commands, etc
  Added a New Command to Display CDRs to Customers

Created cdr_repo and now call it from a new command in the Bot, then filter the response through a form to display for the customer.
Refactored some aspects of lib/cdr.rb.

This prepares the system for prepending customer IDs with 'c'.

LCA is only allowed on number prefix and rate centre search

This reverts commit 8433c3e2df6aa066cb5952325464e6b0a3257542.

* contact-support-directly:
  Switch from unbilled to direct targets
  Allow SGX with a node

An admin can now add a transaction to an account without having to log
into the DB.

A few notes:
- The transaction ID allows a "%" in it which gets substituted with a
  unique value. This is so if you've got a transaction value already,
  like an Interac Transfer or something, you can just put it here.
  But if I'm making something up like "cash" I don't have to mash the
  keyboard just to get a good ID. I can just use "cash_%" and be content
  that I'll get a good value
- The notes have a few prefilled values, which is just there for
  convenience and consistency.
  They're an open list, though, for manual things. Except on clients
  that don't support open lists...
- There's an option to notify the user. I haven't built that in this
  commit and will come later. This is so that under normal operation we
  don't have to message from support and tell them "hey, we've got your
  money", and even better we don't have to tell them "hey, we've got
  your money, you may want to go talk to the bot to activate".

  But if support is already talking to them, we can disable it and tell
  them things in a more organic way.

  Like I said, I haven't built that in this commit, though.

So, this is a start, at least.

Now that Transaction acts as a kind of repo, there's two other methods
I'm going to want for the future.

This is a refactor that involves pulling the Credit Card stuff (meaning
braintree) out of the Transaction stuff. This makes Transaction a more
generic implementation of our Transaction table.

This commit should maintain the status quo, though. The places that used
to call Transaction.sale now call CreditCardSale.create, and that got a
little easier because we now do the `.insert` inside the create, because
previously all the callsites just got the transaction out and then
inserted anyway.

So they got a little bit simpler, but the main value of this is that now
we can insert other kinds of transactions and not just credit card
transactions!

* command-icons:
  Add emoji icons for each command

Instead of just having a list of targets we don't charge for and that don't
count towards limits, instead a list of targets where we know their JID and send
them messages directly, bypassing even the SGX.

In practise we will use this for support.  This means support messages will not
traverse billing code, or the sgx, and will work even if the sgx is down or the
customer has no configuration there at all (or a broken configuration there)
including if the customer has no phone number.

Support will get messages from customer_<customerid>@jmp.chat and can reply to
those.  Customers will still message the support phone number via @cheogram.com
and see the replies coming from the support number.

Anyone messaging the support phone number from outside our system (ie from
carrier SMS) will still show up as phonenumber@cheogram.com to support, since
that won't traverse this path.  If someone messages support without a cheogram
route that will still come as whispers since those don't traverse sgx-jmp at all
right now.

In the unlikely case that someone has a cheogram route set, but no customer id
at all, then these will come from <escaped jid>@jmp.chat and currently cannot be
replied to, but at least support will see that something is up and be able to
take action.

This is not common, but if that's what the config says we shouldn't erase the node.

In Ruby 3 hashes no longer work as keyword args like we expected, so we
have to be a bit more explicit.

Should be compatible with Ruby 2.

Renamed lib/customer_finacials.rb to lib/customer_financials.rb
Edited the 'require' in lib/customer.rb and lib/financial_info.rb

* simpleswap:
  Integrate SimpleSwap into alt top up

Allow choosing Done, Add Bitcoin, XMR, or ETH with the last two being SimpleSwap
swap addresses (and thus only one-time use, for safety, we don't know how long
they keep a record of swaps etc).

* low-balance-target:
  Fix linter, integrate patch feedback
  Add low balance/auto top up with target amount

Canadian ports need this extra info to port them in. Up until now I've
been messaging people manually to ask for it, but that adds a delay to
the porting process since I can't move forwards until they've told me,
and it may be hours between when they fill out the form and when I'm
processing it.

So this will just ask for all the data upfront, meaning I can fully
process them right away.