* porting:
  Porting Script
  Porting Logic
  Add CommandExecution to BlatherNotify
  Import Blather Notify and ToForm from JMP Pay
  Allow User FWD to be Nil
  Move to New Blather Version with Better IDs
  Update ruby-bandwidth-iris Gem

This does a few things. It's meant to be run headlessly, but it can also
be run by a human if they want to do it manually.

So in pursuit of that it has a few options. The defaults ignore
informational logs, send exceptions to sentry, warnings to a pubsub
channel, and send messages to the customer to tell them the port is
finished.

But the manual mode logs informational messages, warnings, and errors
all to the terminal. And then it can either also log the things it would
have said to the customer, or it can send those automatically still.

I've also got an option for making fake ports. Yeah, it's just used when
testing the thing, but given that I run it that way 90% of the time, it
felt weird to just have it floating around in my working dir and having
to keep remembering to take it out, commit, put it back, etc.

So I just decided I'd put it in here behind a flag.

Ok, so I've built a big tree of states here to represent us trying to
figure out what the current situation is in this mad world.

Then each one of those leaves has some thing that it does to hopefully
move towards the next step.

There's also the warnings which are emitted, while also still attempting
to make progress. We want to tell people about things, but not get stuck
in "busted" mode forever.

This follows a single command through a chain of steps and takes care of
the flow where sometimes I fetch a form before I submit it, and other
times I've already gotten the form on the last step, etc.

These are some helpers I'm going to use to run my porting logic later.
I've imported BlatherNotify verbatim here, though I will be making
changes in later commits.

ToForm on the other hand has been just added to the existing Form
refinement we already had, making it a two-way conversion now.

The data-model supports it, so we probably shouldn't crash

This is currently just my branch, but we'll move to another commit after
it gets merged.

This commit makes it so session IDs and IQ IDs are unique rather than
the current state where they're always blather01, blather02, etc.

Given that we just start, run roughly the same commands, and then close
it meant all of our sessions were predictably numbered, and so we were
seeing some previous runs of the script picking up old sessions, etc.

Not great!

Also, at some point between whenever the last version was and now the
API changed for handlers, so we have to do that now. If we don't, the
commands just sit there and never respond. Bad.

So this makes our extensions more inline with upstream's new API.

It looks like the commits on this branch were merged to upstream a long
time ago, and other changes have been made since which I'm going to need
in a moment.

Gives it more structure, and also makes cut-paste easier in the app.

They don't really know their throwaway onboarding JID anyway.

NOTE: they have a customer ID but not a cheogram route, so contact from support
must still go via whisper to their JID and not direct to this customer ID!

I decided that when undoing this action I shouldn't delete the new
number automatically, and when redoing I probably shouldn't re-delete
the new number.

This situations are weird, and so the human should probably think
criticially here.

So what I do instead is only delete the number the first time the action
gets run, and then in the other two cases I warn the operator that I
didn't delete anything so they can go figure stuff out.

I put this `first_time?` logic in the parent because I already know of
another place where I'm planning on using it in a different PR.

I'm going to make changes to this file at some point, but while I was in
here I noticed the whitespace was a bit weird.

So this change is only whitespace, no logic.

* 3ds-tx:
  Privacy.com doesn't even like us anymore
  3DS first transaction

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.