handle changed safety numbers

NOTE: this issue subsumes #70 (closed), #86 (closed), and #87 (closed)

Value

• When a user re-installs signal on a new phone, they should be able to continue using signalboost.
  • (Currently they cannot because their safety number changes, signal does not trust it by default, and signald will therefore not read or send messages to them)
• When an admin changes their safety number, we would like them to be blocked from sending by default so that other admins may ensure that they are not being subjected to an impersonation attack before restoring priveleges

Context

• The only possible way to observe that a user's safety number has changed is to try sending them a message and then observe that it has failed [1], in which case signald emits an error message with a known form.
  • (Even if you poll for new safety numbers after you know a user has reinstalled signal, you will not see the new safety number until after signald has attempted to send that user a message and fails.)

Behavior

Self-healing scenario:

GIVEN a subscriber alice on a channel 'foo' who has just reinstalled Signal (thus triggering a safety number change)

• WHEN any admin sends a broadcast message to 'foo'
• THEN signalboost will notice that signald was unable to send the message to alice
• AND THEN signalboost will direct signald to trust alice's new safety number on 'foo'
• AND THEN signalboost will resend the message that originally failed to send to alice on channel 'foo'
• AND THEN all subsequent messages on 'foo' will be delivered to alice as if nothing happened

Admin re-adding other admin scenario (after failed message send):

GIVEN an admin bob with phone number +1-555-555-5555 on channel 'foo' who has just reinstalled Signal

• WHEN any other admin sends a broadcast message to 'foo'
  • THEN signalboost will notice that signald was unable to send the message to bob
  • AND THEN signalboost will remove bob as an admin on 'foo'
  • AND THEN signalboost will send an alert to all other admins that bob has been removed and must be re-added
• WHEN another admin sends the command ADD +1-555-555-5555 to 'foo'
  • THEN signalboost will restore bob's admin priveleges on 'foo'
  • AND THEN signalboost will direct signald to trust bob's new safety number on 'foo'
  • AND THEN signalboost will send a notification to all admins that bob has been made an admin (and by whom)
  • AND THEN bob will now be able to send and receive messages as if nothing had happened

Admin re-adding other admin scenario (before failed message send):

GIVEN an admin bob on channel 'foo' who has just reinstalled Signal

• AND GIVEN that no other admin has yet sent a broadcast message on 'foo'
• WHEN another admin sends the command ADD +1-555-555-5555 to 'foo'
  • THEN signalboost will restore bob's admin priveleges on 'foo'
  • AND THEN signalboost will direct signald to trust bob's new safety number on 'foo'[1]
  • AND THEN signalboost will send a notification to all admins that bob has been made an admin (and by whom)
  • AND THEN bob will now be able to send and receive messages as if nothing had happened

Maintainer re-adding admin scenario:

GIVEN an admin bob on channel 'foo' who has just reinstalled Signal

• WHEN a maintainers sends the command `boost add -c -a
• THEN admin will be re-added and welcomed and other admins alerted as above

Definitions

• [1] The failure message from signald looks like this:

{
  "type":"unexpected_error",
  "data":{
    "msg_number":0,
    "error":true,
    "request":{
      "type":"send",
      "username":"+1<REDACTED>",
      "messageBody":"[TEST_WELCOME]\nHi",
      "recipientNumber":"+1<REDACTED>",
      "attachments":[],
      "expiresInSeconds": 0
    }
}

• further descriptions of protocols to re-activate an untrusted safety number are contained in #70 (closed)