We added group picture message receiving support in d89a1b7, but the
API introduced there (as part of the send_media method) was not ideal
due to the caller having to worry about the deep clone.  So instead we
will move the .copy() into send_media() so that it worries about the
deep clone and the caller doesn't have to care.

When we first added proper incoming group text support (in 90331bc),
we only supported 2 recipients.  We also assumed the first recipient
was the user, and then just truncated the rest of the recipient list
to be just one additional number, as a way of getting it implemented
quickly.

Now we've added a bit more thought, and a loop to go through all the
recipient numbers to add them to the address list we pass on to the
user.

We also needed to be careful to filter out our own number from the
recipient list, as that is already added in the addr1 section above.

Prior to this commit, picture messages sent to a group would appear to
come from just the sender, without any mention of the group (i.e. as
if the sender had sent the picture only to the SGX user).  With this
change, picture messages are correctly shown as being from the group,
utilizing the address list creation added in 90331bc.  Note that a
deep clone of the template message is required (via .copy) to ensure
that send_media() doesn't modify the original, which often contains
text that we need to send separately (done later in the code).

Since the media is stored at a completely different place with the V2
API, we need to update the send_media() method accordingly, so that
media (such as picture messages) is passed on correctly.

While this still technically requires an update to mpx-catapult, that
is beyond the scope of this project for now, particularly because it
is a very minor change there (it will remain in sgx-catapult for now).

So with this fix the URLs will be correct, assuming that the
mpx-catapult serving up this instance's URLs has been patched
accordingly.

We added some hacks to not send delivery receipts for group texts (as
they were not working correctly with Cheogram in our initial tests),
but we did not properly combine them when the second was added, in
part to keep the diff looking pretty.

So we'll do this now, noting that the first hack was added in d49bf12
and then a copy of it was added in a106c87.  Now they are combined.

This almost has no functional changes, except that if we were to
receive a message with an unknown type for a group text, the
corresponding message would no longer be printed due to this warning
and early exit occurring first.

This is similar to the support for message delivery receipts
themselves, so it's actually just as simple as checking for the
correct 'type', and the importing the two hacks that we already have
for message delivery receipts, namely those in b277759 and d49bf12 -
we probably want to move them into a common area eventually, but this
is fine for now, and definitely works in our tests just now.

While maybe a bit awkward (as the conditional is left until the end of
the statement), this fix for a non-present 'media' element sure does
make for an elegant diff.

With this, the SGX works at least as well as at it did before cd6e0df
(i.e. as of d49bf12) but the MMS ("picture messaging") support added
in cd6e0df does still need some work as mentioned there.  In
particular, we need to ensure that the media is accessible to the
user, which may necessitate us bringing back mpx-catapult in some form
(it was deleted in b1aabae).

Move the media handler code from the now-inactive 'mms' block (since
V2 messages don't have that type) into the new 'message-received'
block.  While this does cause the user to receive the media message,
there are still at least two problems:

1. This commit breaks non-MMS messages (since 'media' is undefined).

2. Media messages are not delivered with the correct URL (needs mpx?).

Anyway, we know about these, but wanted to keep this commit short and
sweet so that changes to the actual media handler are separate from
the commit that merely moves the code from one place to another
without changes to the media handler code itself.

Currently there is an interaction bug between this SGX and Cheogram
where Cheogram sends its "Instead of sending messages to cheogram.com
directly..." error if we naively send delivery receipts for group
texts.  This might be related to us sending two separate delivery
receipts with the same ID, but it's still unclear exactly what the
issue is.

So until we solve the problem that causes us to not be able to send
delivery receipts to Cheogram, just turn off that functionality.

This functionality wouldn't work anyway since Cheogram does not yet
support subscription requests on porcelain JIDs, which means we can't
test delivery receipts in most clients (as they need a subscription
before they will enable receipts).

Delivery receipts (at least for single-recipient messages) now work
correctly with the V2 API.  This was mostly simple changes (just
needed to change the deliveryState == 'delivered' check to instead be
type == 'message-delivered'), but did require a bit of a hack because
of the way we decided to determine the source and destination numbers
in d2e2d92 - there's probably a cleaner way, but we'll just go forward
with this quick fix for now, and do a better job of it later (which
may be needed anyway once we do (likely required) additional work for
multi-recipient message delivery receipts.

We discovered this while testing message delivery receipts, which
fortunately included the word "Gajim" in the messages in our tests,
causing Goliath to bail with an HTTP 400 error, indicating bad JSON.
Which was correct, since we would only have been sending the JSON part
before the 'G' in Gajim, due to incorrectly failing to limit the
number of splits being done by the split that is fixed here.

That will teach me to parse JSON without a JSON parser, or not...

Per https://wiki.soprani.ca/SGX/GroupMMS we have implemented the
protocol for receiving group texts.  For now we hard-code
"cheogram.com", but this and other items will be fixed in the near
future.

While the message going out does look correct, the current Cheogram
takes issue with it, sending us back the following error:

<message to="cheogram.com" type="error" from="<from>">
   <body>Instead of sending messages to cheogram.com directly,
   you can SMS your contacts by sending messages to
   +1&lt;phone-number&gt;@cheogram.com Jabber IDs.  Or, for support,
   come talk to us in xmpp:discuss@conference.soprani.ca?join</body>
...

So this code might not be complete, but we won't know for sure until
we're able to do a bit more Cheogram testing.  But it could be ready!

Also, we only currently handle group texts with 2 recipients - any
additional recipients will be dropped.  It should be trivial to add
more recipients by looping as needed.

Now we get a normal message via XMPP on a V2-style JSON blob, after
fixing the type info.  Group texts are not yet handled - that will be
next.

Now we get even further than in 6abd653 - since we have updated the
'to' so we use 'owner' instead, which is a string instead of a list.
In particular, we now get a message delivered (woo!), though it's of
the form:

'unknown type () with text: <text>'

So still a bit of work to do yet.  Also, we updated a couple other
fields with their appropriate analogs.

Thanks to 4607bb5 we now had params moved out of the way (since we
can't re-assign to this special variable) so we could now just simply
assign the JSON block to the new params variable (jparams).  Since the
Bandwidth V2 API differs a bit from the V1 API (on which this file is
based), we had to comment out some parameters for now, and change
'messageId' to 'id', but other than that the parameters at least
exist in V2.

However, this still doesn't cause the message to flow completely
through the SGX, since we haven't fixed the 'to' parameter, which is
now an array in V2, and so we now get something like:

'jid_key (catapult_jid-["+14165551212"]) DNE; BW API misconfigured?'

But this is way better than crashing the SGX, which is what we got
when passing in V2 messages before this fix.

So we're well on the road to getting V2 messages all the way through
the SGX and probably just need a couple minor fixes now.  Yay!

We previously sent the JSON blob that included the translator- and
acceptor-generated timestamps.  However, it is better is the SGX just
receives precisely the JSON that Bandwidth would have sent it, as that
makes it more easily compatible (i.e. if you want to use the SGX
without the acceptor and translator in front of it).  So we do that
here, being careful to pass on valid JSON (otherwise Goliath will have
an HTTP 400 fit).

Since it is easier to manage an HTTP connection between SGX and
translator, and this is likely how it will be used going forward,
remove the default of listening on all interfaces and instead just
listen on the loopback interface.  Managing HTTPS is beyond the scope
of the work here, and that would be required in order to safely listen
on other interfaces (and if you know it's safe for your situation, you
can of course just change the hardcoded value back to '0.0.0.0').

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.