This crash is particularly bad because it currently causes
sgx-catapult to get stuck.  We'll fix that in a future commit.  Also,
a future commit will apply this fix to the other tagged message send.

See merge request !5 for the discussion and details behind this merge.

Since id is not strictly required on messages, and bare JIDs can
certainly send message stanzas.

I must not have looked at the spec when I wrote this disco value; it
seems pretty clear that "sms" is indeed the right string to use:

https://xmpp.org/registrar/disco-categories.html#gateway

See merge request !4 for the discussion and details behind this merge.

This does not appear to have any functional changes so I'm happy to
merge something that gives us fewer dependencies.

See merge request !3 for the discussion and details behind this merge.

Saves us a whole dependency!

Rather than always sending a <conflict/> error back if we encounter an
existing registration, we first check both the catapult_jid-<P> and
catapult_cred-<J> keys.  If either or both of them exist and at least
one has a different value than the user's, then we still return a
<conflict/> error.  Otherwise, we set the values that the user entered
and indicate a successful registration.

This has the added advantage of allowing a person to easily fix a
partial registration.  Such a thing is unlikely, but possible, given
that the setting of catapult_jid-<P> and catapult_cred-<J> are not in
the same transaction, and sgx-catapult could go down mid-registration.

Making this change was much easier thanks to the a66b574 refactoring.

We did have to relax some RuboCop parameters a little bit to make this
happen.  But I consider these worth it, as this also commit also fixes
two much more serious RuboCop infractions!  Here are the relaxations:

* Metrics/ParameterLists - increase by 1 from default; need for method
* Style/AlignParameters - off, as RuboCop too dumb to check 8-col tabs

The one item I might change later is to put the parens back on
user_cap_identities and user_cap_features, but it's not that big of a
deal so I'll leave them for now.

See merge request !2 for the discussion and details behind this merge.

I have no idea how this ended up in here - it must have worked at some
point during testing, but something must have changed since then.  In
any case, proper registration wasn't being heavily tested (since most
people get registered via the jmp-register "side channel") but we want
it to work, especially if we're going to have more Cheogram users.

Configure rubocop linter and fix some inconsistencies in the existing code.

This is slightly related to #3 as we need to use <registered/> there
as well.  And this commit should also make it less likely that the
user will hit the "tries to register again" case mentioned there.

See merge request !1 for the discussion and details behind this merge.

Fill in the non-secret part of the form (the phone number they are
currently registered with) and send back the <registered/> element.

We don't support delivery receipts or picture messaging with this
feature yet - those should be straight-forward and are coming soon.

This mirrors what we did in jmp-fwdcalls commit 5901c10, but also adds
some more newlines to make it look nicer (which jmp-fwdcalls had
already).

Note that both mpx-catapult and sgx-catapult are being updated here;
aside from the new log line printing, there are no functional changes.

The "catapult_num-N" keys have always stored the JID associated with N
so it makes more sense to call this "catapult_jid-N" - this is really
a "JID key", not a "number key" (hence the accompanying variable name
change).  Furthermore, we will be adding another number-indexed table
to the schema soon ("catapult_fwd-N"), which will eventually be used
for forwarding calls, but is initially mostly a placeholder in the DB,
used only for sending verification codes via phone from jmp-register.
It makes much less sense to have "catapult_num-N" in this situation.

This is for compatibility with jmp-register commit f7ee1fe (whose code
is not yet active), and for general simplicity and correctness.  We
can now use SETNX to mitigate races rather than set-then-check-length.

Thanks to singpolyma for the suggestion; use more Ruby-isms as I can.

This change was suggested by singpolyma; looks more correct to me too.