So that we have a model we can save/load and not just the XML element

* snikket:
  Welcome message after final jidswitch for onboarding
  Finish onboarding by creating a Snikket instance

Changed the SIP account creation and reset command to prepend a "c" in
front of the customer_id.

Added template item for Data Topups.

* reg-new:
  Show Bitcoin registration info as form not note
  Include customer id when onboarding

Custom domain not supported by the API yet, so stub for now.

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