Updated a log message to remove TODO as we won't be putting the ID of
the message in the log, for privacy reasons.  This also means that we
won't have any need to read JSON anymore, so we can delete that
"require 'json'" line as well.

Added a TODO about handling another return value (of INCR).  This
probably isn't a big deal either way, as an INCR returning an error
multiple times will result in duplicate archived_message keys that
will be caught elsewhere, but there is still a small chance it won't
be caught, so it would be good to fix eventually.

We've taken care of a number of TODO items in this commit, including
checking if the archived_message key exists before setting it, adding
warnings about how this program should be treated as a singleton until
some extra atomicity is added, adding a couple TODO items, and finally
have the pending queue being managed correctly (checked at launch time
to confirm emptiness, then popped and checked again after processing a
message).

With this change, all of the queue state is now managed correctly, so
the translator can be run without needing to manually futz with the
queues between each invocation to get them in the right state.

However, there is still more work to do, as the translator does not
yet communicate correctly with the SGX (due to some of the remaining
TODO items, specifically related to how the HTTP request is sent).

Fix incrementing of the daily message total so that it doesn't use the
EMPromise-style code imported in 07bcf9c - this code works elsewhere,
but we're not using EMPromise in this file so use the more sequential
method of coding (that works here) instead.

Also add the saving of the passed-on messages to the archived_message
keys.  This is done with the 3-day (259,200 seconds) expiration per
the just-removed comment.

The code as of this commit has been tested now, so it does actually
run - the previously version (in 07bcf9c) did not run due to the
aforementioned EMPromise issue.

Now that group texting is supported via XEP-0033 (per a91a575) we are
removing the old way of doing group texting, which effectively reverts
6de670f and then 96856c7.  We won't be supporting both ways of group
texting going forward, so delete this to avoid future confusion.

Now the XEP-0033 support indicated in 8e8fa1b is actually present, and
allows the SGX to receive group texts in this manner per the details
in https://wiki.soprani.ca/SGX/GroupMMS - the other method added in
96856c7 remains as of this commit, but will be removed shortly.

Note that the method parameter for validate_num had to change slightly
here, but the single-number validation code needed no changes at all.

The XEP-0033 support is per https://wiki.soprani.ca/SGX/GroupMMS - we
don't actually support it yet, but we will with subsequent commits.
Just turn it on for now to confirm Cheogram sees it.

The acceptor (h2r-bwmsgsv2.php) will receive the messages from
Bandwidth via HTTP and put them in a Redis queue.  Then the translator
(r2s-bwmsgsv2.rb) will pick them up from the Redis queue and direct
them to the SGX (sgx-bwmsgsv2.rb), removing them from the pending
queue if the hand-off was successful.

The above components were added in order to improve resiliency of the
system, especially in situations where the SGX may become unavailable
for long periods of time.  Bandwidth will send the message again if it
is not received the first time, but it no longer stores the messages
itself in V2, so the consequences of missing an HTTP request are more
severe than in V1.

Analogous to fix for https://github.com/singpolyma/cheogram/issues/71 .

See merge request ossguy/sgx-catapult!18 for the discussion and details behind the merge.

https://xmpp.org/extensions/xep-0030.html#info-nodes requires that *if*
the query includes an optional node, it should be included in the
response.

Added a feature that allows the user to send a real MMS (e.g. picture
message) when using their server's HTTP Upload (XEP-0363).  With some
clients, like Conversations, the resulting file is sent via OOB, so we
use the presence of a URL in the OOB section to indicate a file is to
be sent.  Other ways of describing the URL are for now unsupported, as
we want to ensure that we only do this when the user implies that they
want to send a file.

For a number of reasons, this feature is gated on a per-user flag,
which is off by default.  The user may be used to the old behaviour
and not want a real MMS sent, or they may be confused if this feature
breaks when it didn't before (i.e. the carrier supports larger files
when sent via "internal" URL, as is done with Jingle File Transfer,
than it does when sent via "external" URL, as is done here).  A new
option will be added to jmp-acct_bot shortly to let the user set this
flag.

When the user tries to send a message to an "anonymous" JID (the type
of JID that jmp-fwdcalls will create when it gets a blocked caller ID,
as of https://gitlab.com/ossguy/jmp-fwdcalls/commit/e2032c8 anyway)
provide a more appropriate error message, as the JID does exist, it's
just that the user who left the voicemail isn't available at that JID.

Some clients expect <error/> first and we should always set the type
to :error regardless.

See merge request !17 for the discussion and details behind the merge.

Every error is of type error, and put the <error/> child first for
broken parsers that only get the first child.

This probably doesn't appear much in the wild, but good to have in
case we do see it.

See merge request !16 for the discussion and details behind the merge.

Empty and whitespace-only bodies are banned by catapult API, so return a
policy-violation error in those cases.

Closes #12

Works well in my tests and, from my understanding, will be helpful in
fixing https://gitlab.com/ossguy/jmp-fwdcalls/issues/7 .

See merge request !15 for the discussion and details behind the merge.

Mostly useful for extending the existing SGXcatapult application from
elsewhere.

I don't normally kill sgx-catapult from the command-line so my tests
just cover use via Monit, but it worked fine in those tests so seems
good to merge.

See merge request !14 for the discussion and details behind the merge.

The unused `subscription(:request?) do |s|` section became used when
we switched Blather to stop processing a stanza on the first matched
Ruby proc in 6d19b7f.  It was added way back in the first week of
sgx-catapult development and hadn't been touched (or likely thought
of) since.  So it's about time we deleted it anyway.

This does cause subscription requests to work again in my testing.

See merge request !13 for the discussion and details behind the merge.

Defer the stop to happen outside of the trap handler so that EM won't
freak out about it.

There were two handlers -- the more specific one was commented out? And
now that we only run the first matching handler, this caused all
subscriptions to be eaten.

Needed for https://gitlab.com/ossguy/jmp-fwdcalls/merge_requests/1 and
also adds optional subject and description parameters for filling in
the respective fields on the XMPP message (not used yet).

See merge request !10 for the discussion and details behind the merge.

Makes more sense there, and gives others who want to use it easier
access.

As mentioned in 889024e, 7729a26 had the side-effect of adding the
params values to the log.  In the spirit of 349d8b0, we are trying to
keep such values out of the log, so explicitly remove them to retain
the old (and desired) behaviour.

In 7729a26 the Redis parameters were moved such that the `REDIS_URL`
environment variable must now be used instead.

In 7729a26 a `use Goliath::Rack::Params` was added, which changes the
behaviour when printing the `env` in `response(env)`.  This will be
fixed in a later commit.

In 5f00e6d the XMPP features list advertised by sgx-catapult has been
fixed.  This is long overdue and good to have corrected at last.

See merge request !9 for the discussion and details behind the merge.

Also, remove advertisements of support for things we don't currently
support.

Defer executing the event loop until exit in case someone `require`s us
and wants to install extra stuff before we run.

Some small tweaks to the APIs to make the coming fwdcalls plugover
easier.

Also, normalise to use REDIS_URL environment variable instead of passing
host/port in args.

In particular, tested SMS send/receive (shouldn't have been impacted)
as well as the registration form display on an already-registered
account (using Cheogram's "Configure direct message route" ad-hoc
command).  Both appeared to work fine.  Since we don't currently use
much more than this in JMP (most registration is done behind the
scenes and Cheogram mainly uses registration for verification reasons)
that should be sufficient testing for now.

See merge request !8 for the discussion and details behind the merge.

Now everything uses EM and there's no blocking IO!

Also, fixes stalls caused by Blather mixing threads with EM by default:
https://github.com/adhearsion/blather/issues/130
https://github.com/eventmachine/eventmachine/issues/779

The last one (!11) wasn't quite right, but with this #8 is now fixed.

See merge request !12 for the discussion and details behind the merge.