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.

* use-tel-we-have:
  Skip asking backend about registration when we know the tel already

* fix-info-when-no-plan:
  Fix rendering info when there is no plan

* outbound-call-customer-not-found:
  Actually handle outbound attempt from unknown customer

This is an optimization.  If we are looking up by tel already, then we don't
need to ask the backend sgx if they have a tel or what it is, we know that, so
just use that information directly and save us a call.

V3 commit.

	modified:   forms/admin_menu.rb
	new file:   forms/admin_number_change.rb
	new file:   lib/admin_actions/number_change.rb
	modified:   lib/admin_command.rb