Not on our inbound-facing JID.  This is why we shouldn't be mucking in the SGX's
Redis at all...

Turns out every user will start with no attempts, and the code wasn't
handling that case. Oops.

Not typing indicators, etc.

Notify only once per day (using expiring redis key).
Can notify MUC or user, always sends directed presence first so it will join MUC
if not joined.
Ignore all messages direct to the component, mostly to throw out live messages
from MUC if we join that to notify.

Just gives them the information and we're done. Support has to manually process
these payments anyway.

To show mailing address, eTransfer address, Bitcoin addresses, and allow
generating a new Bitcoin address.

An invalid customer id is an error from braintree, so handle the error and
return an empty list of payment methods.

Also rename buy credit to top up

And use that in registration instead of implementing it inline

So say feature-not-implemented if we haven't got it with some other handler.

* conditionally-show-commands:
  Only show buy credit option if customer has a plan and a credit card
  Show commands conditionally (plus add voicemail record command)

Refactor to a factory that allows commands to be shown conditionally, so that
the voicemail record command can only be shown if the customer has a forwarding
target set up.

* credit-card-bonus:
  Insert bonus when paying by credit card

* tel-search-temp:
  No tel picker yet, so just go to the webpage

Otherwise we go in hierarchy order and stanza comes last.

* passthrough-commands:
  Pass through commands we know the SGX can handle
  Pass everything from SGX to user, not just <message/>
  Remove some of the noise from the command list

* bitcoin-tmp:
  Save legacy session for Bitcoin flow

Typo not caught by tests because this method had none.  Add a test, fix the typo.

These lines won't work because not processing an iq or anything with a node
here.  Set up sentry in a sensible way for messages.