If it's not a one-use code, save it as a pending code for later use maybe.

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.