In the pre-refactor code, response.to_s looks something like this:
"#<Net::HTTPOK:0x00000002b8dad8>".  After the refactor in ff64421 the
chosen replacement value (http.response) outputs the entire body of
the response instead, which is more than we're looking to log.  So
remove it entirely ("#<EventMachine::HttpClient:0x00000001d6b810>",
the value of http.to_s, is even less useful than response.to_s was)
and just print the response code on its own in that line now.

This happens to fix an 80-column violation introduced in ff64421 as
well, which we should probably have checked by RuboCop at some point.

Note that the EventMachine upgrade is required here since "1.0.1 fixes
a bug with the use of epoll, which goliath's runner enables", per the
merge discussion.

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

Instead of writing our own, just use the built-in Goliath runner.
This changes the usage, new usage is:

REDIS_URL=redis://localhost:6379/0 bundle exec mpx-catapult.rb -p $PORT -s -v

There is a --help for more information (provided by Goliath).

Instead of using blocking I/O, use EventMachine.
To be consistent with the rest of the project, use em_promise

This looks very good to me and worked fine in my testing (including
most of the cases that result in errors being returned to the user).
The changes should make sgx-catapult much more performant (especially
as we handle more load) and are generally the right thing to do.

There are a couple of minor fixes that are included in these changes
that would ideally be broken out into separate commits, but I won't
push for those here as the important part is the resulting code.

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

This fix introduces several "C: Use 1 (not 0) spaces for indentation."
RuboCop offenses due to the introduction of begin/end blocks that seem
to be required inside each Ruby proc that needs a rescue section.
There wasn't an obvious RuboCop setting to disable, and it's probably
worth fixing in a better way eventually, so leave them in for now.

We did have to disable the RuboCop check for "rescue Exception", which
is used liberally in this commit.  In our situation, doing so is ok,
since we really do want to catch every single type of exception.  It's
fine to do so since we're exiting every time regardless of the issue.

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.