There are edge cases with SMS/text message sending that we aren't handling

[toolness]

The implementation for sending text messages was originally written with the assumption that sending a text was similar to sending an email, but over time this has proven to not be the case, and there are some edge cases we ought to handle better:

• If we send too many text messages over a short period of time from the same number, we get a "SMS queue is full" error from Twilio. For more details, see #2057.

• Once-invalid phone numbers can become valid; see #1738.

• If the user has responded to our text message with the word "stop" (or a handful of similar words), Twilio will put them on an internal blocklist and all future messages sent to them will fail with Error 21610 "The message From/To pair violates a blacklist rule". As of #2091, we are at least not reporting these as errors, but we might want to do something more robust, like not even bothering to send messages to recipients that we know have blocked us--see #2090 for one attempt at that.

• Just because we get a sid for the text message we've sent doesn't guarantee that it will actually arrive at the recipient's address (although this is technically true of email as well, it's probably more likely for SMS messages to go undelivered due to e.g. the user's phone being out of cell phone range, being turned off, etc). Some platforms use Twilio's status callbacks to get information about whether a message was actually sent, though I've informally been told by some developers that this isn't 100% reliable, so we should also use Twilio's REST API to ask about messages' status too.

• There are even more! See Troubleshooting Undelivered Twilio SMS Messages for more details.

Fortunately, most of the SMS messages sent from the Tenant Platform are currently intended to be optional, rather than critical communications, so this isn't a huge deal. But as we expand our SMS offerings, they will become more of an issue.