~singpolyma/cheogram

Replace sendMessage, componentJid, from with sendText

It's funny, I built the "sendText" method for my cancellation logic as
an easy way for it to send some status messages to the user. After I
looked at it, though, I realized that's just what I always wanted. I'm
not sending any special messages back to the user, just text, and I'm
threading these arguments all the way through the logic just so I can
build a message from text at the bottom.

That's dumb, so now I'm just doing it at the top and injecting that.
Adhoc Session Cancellation and Timeout

This allows a user to bail-out without committing to anything. So they can type
"cancel" at any time to get out of the thing they're in the middle of and it'll
send the cancellation upstream to the provider, and then clear the session out
of our local set.

The same thing happens if the user disappeared part way through our
conversation, configured by a value in the code.
Maybe we could move this configuration out to the config file at some point,
but this is probably fine.
Merge branch 'adhoc-ready-for-users'

* adhoc-ready-for-users:
  Show current value and description (if present) along with label
  Don't hide it anymore, send the help text to anyone who asks.
Show current value and description (if present) along with label
Don't hide it anymore, send the help text to anyone who asks.
Merge branch 'cv_adhoc_squashed'

* cv_adhoc_squashed:
  Change Case to Select
  Add Thread to Bot Responses
  Add Text-Single Handling
  AdHoc Bot Forms
Change Case to Select

I was abusing the case syntax pretty hard, so this should be more accurate to
what's actually going on.

I was going to reintegrate this change back into the earlier commits, but I've
fixed that same ugly merge conflict when the new stuff gets added in the case
statement like 10 times by now, and I'm just not interested in doing it again.

So this is its own commit, at the end.
Add Thread to Bot Responses

It may help some clients do something clever with the responses, and it's not
hard to build.
Add Text-Single Handling

The standard even says that this should be the default, and I had a spot for
"things I don't otherwise have a handler for", so that's convenient
AdHoc Bot Forms

Before this when a user got back a form it was considered an error. Only
commands that returned a note could be executed.
Now, though, we see the form and try to handle it as a series of chat questions
asked to the people. This is only the first version of the technique, though,
so it has some pretty strong limitations.

First, it only supports lists because that's all the test flow I pulled out of
the spec had in it. There are obviously other field types that this will need
to support to be considered finished.

Second, it only goes forwards. There's no cancel, no returning to previous
questions, etc. It also waits forever (well, until the next restart) for the
user to finish, occupying memory in the session holder until then. We could
also maybe ask confirmation before crossing from one form to another, from the
server's perspective, since there's no guarantee that changes made aren't
immediately applied, rather than waiting for the end. At the very least we
should have timeouts and cancelling though.

Third, there's no error handling at all. It just takes things and assumes
success. That should maybe go along with cancellation, at least, but handling
it with some kind of error message and retry may be nice, if the standard and
the server command accepts it.
Handle Group Jingle Messages

The old jingle handling was constructing a message, and then passing it through
part of the message processing system to try and get a resulting message that
would go out to the backend.

But not all the logic lived in that part of the processing pipeline. The group
logic, in particular, lives on the ingress side where I get a message from the
user, and translate it into a message with multiple receivers.

So, to try and bring these together I've instead pulled the receiver apart from
the XMPP bits a little. So now there's a new thread that just pulls from XMPP
and puts on a channel, and the actual handling logic pulls out of that channel
and processes it.
That logic barely changed at all.

But what that means is that our Jingle code can now produce a message that
looks like the user sent it directly, and then push it in the front of our
pipeline, as though the user sent it directly. Rather than the half-and-half
approach from before.

Hopefully this kind of approach also avoids future issues where we want to
produce something and want it to work in all cases. There's nothing about
Jingle in particular in the fix, really.
Relax Dhall Version

I constrained it to the one version I happened to have installed to ensure it
worked. Now that I have more time, though, I've tested and it appears to also
work on these other versions.
Accept an Error to Backend Presence Request

We didn't want the backend servers to be required to support these kinds of
requests, but if we don't handle error on these then the client will never see
numbers as online.
Update Dhall to Newer Version

Some classes changed names, others changed types.
All in all it was a relatively straight-forward port.
Terminate Jingle Sessions After Transfer

The spec for Jingle claims either side can terminate the session, but suggests
that the receiver should, since it knows when it's received things.

The current code expects the sender to do it, and Conversations expects the
receiver to do it, leading to both sides waiting for the other to do something.

So to fix that, Cheogram needs to send a session terminate once the upload is
complete!

At some point this logic, and the optional "received" that's already there,
should live inside the Jingle library, since they're related to the Jingle
session which this code otherwise knows nothing about.

But that day is not today! Today I just want to see this work, and make sure it
doesn't break anything else. Then we can figure out how to move it inside.

Once I had three things there, I put them in do-notation since I felt that was
clearer than what was there, with the ">>) $" thing.
I also considered putting them all in a sub-notation, since they're all being
lifted right now, but decided that would make it harder later, since I'm
planning on pulling this stuff out into the library at some point.
So no need to make things _too_ clean! Gotta feel the hurt!
Ignore message from ourselves

If a message is coming in from our own DID, do not process as that would lead to
a loop.
Better URL block for whispers
Command-only commands work

That is, if the command returns completed immediately with a note, the
note is returned to the user.  Anything else is treated as an error.
Refactor help command to stop using the -and-then resource hack
Only assume nickname for phone number if isE164
Next