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.

* include new copyright line, as the file has an additional author now
* split up the `require` lines a bit as we're not alphabetical anymore
* move/rename the HTTP listen port in the command-line parameters
* revert ARGV change since others missed in 26d6c4f; reordering anyway
* add comment to #write so I remember why it was added to begin with

Demonstrates how to integrate Goliath into your EM reactor alongside
Blather.  And also how to send an XMPP stanza in response to a webhook.