[splash] remove link to wayback machine archive (pending signoff)

See merge request !604

[splash] replace splash site with shutdown notice

See merge request !603

update splash with downtime notice

See merge request !602

[hf] fixup mr !599 - cleanup SignalReceiver/ContactStore

See merge request !601

SignalReceiver:

- make helpers in different branches of `#dispatch` return
  `Unit` instead of `Job?` (we never used the job and it was odd to
  return null from 3/4 of the branches!)
- call `ContactStore#create` with uuid and phone number from
  `#handlePreKeyBundle` (instead of calling overloaded `#create` that
  takes an envelope as arg) to (1) be simpler, (2) make it more
  explicit why we are storing both pieces of data at this
  point in the session lifecycle
- revise the comment for `#handlePreKeyBundle` (it is a "hot spot" and
  likely to be the source of lots of confusion to future us when less
  debugging state is loaded in our heads!)

ContactStore

- revise `ContactStore#hasContact` to be slightly more
  straightforward (if less terse)
- remove overloaded `#create` (which is no longer called)

[#498] Resolve contact ids

Closes #498

See merge request !599

in SignalReceiver:

- fix bug in which we dropped sender address from inbound identity
  failure socket response after identity failure during decryption
  - we no longer have access to sender address in the envelope for
    sealed sender messages, so by default the address is not
    available (and its bad to omit it b/c client needs it to trust new key)
  - however: we can recover the address by getting an identifier from
    the error message (all `ProtocolException`s store a `sender` field that
    is the equivalent of `SignalServiceAddress#identifier`) and use it
    to query the contact store for the uuid and number needed to
    construct an address

in SignalReceiver & SignalSender:

- update unit tests that wrongly used `account.identifier` (defaults
  to uuid) instead of `account.id` (defaults to phone number) for
  contact lookups

in ProtocolStore:

- create contact in test setup to allow calls to `#resolveContactId`
  to succeed

in `SignalReceiver`:
- reorganize execution flow in `#dispatch` to be more cohesively grouped
- add `numberOfMessagesWithoutProfileKey` counter to track messages
  received from desktop app without "continue" being tapped from phone
- move `null` return up into `dispatch` (where it more obviously
  refers to whether or not a job is returned from a branch of the
  `when` statement and the helpers that don't return a job have a more
  sensible signature of `Unit`)
- in `#processPreKeyBundle`: remove unnecessary `withContext` wrapper
  and touch up comments
- in `#processReceipt` remove unnecessary check for
  `isSealedSender` (receipts are always unsealed) and touch up comments

in `ContactStore`:
- overload `#create` to take an account and envelope to make for more
  ergonomic calling from `SignalReceiver`

re: `SignalSender`
- add tests for `#sendProfileKey` and `#sendReceipt` helpers used by
  `SignalReceiver`

(necessary to make removal of non-null constraint safe)

- sadly, `isProfileKeyUpdate` does not appear to be dependably `true`
  on all first messages containing a profile key
- so... we store profile keys on every message (for now)

- (this is needed to create sessions with actual contacts for reasons
  that remain unclear!)

- in m2_WIP, we modified `SignalServiceAddress#identifier` to prefer
  phone numbers to UUIDs (as opposed to preferring UUIDs to phone
  numbers, as the upstream version does)
- we did this in an attempt to attempt to solve a bug that was
  better addressed by making the `phone_number` column on the
  `contacts` table nullable
- here we revert that change it because:
  - (1) it is risky to diverge from mainline signal on this part of
    the data model
  - (2) the change appears to have introduced another bug in which in
    which first-time incoming prekey bundle messages could not create
    a session b/c of a Bad Mac error

feed back authored Jun 14, 2021 and aguestuser committed Jun 16, 2021

[498] Change storeUuid to storeUuidOrPhoneNumber, split resolve into resolve AND resolve or create id.

- testssss!
- there is currently a race in the first inbound message that we think
  can be resolved either by:
  - (1) making the process prekey helper suspend/async/await (so
    `processMessage` doesn't happen until it finishes)
  - (2) doing some refactoring of relationship btw/ ContactStore &
    AccountProtocol store so that ContactStore can know about the
    session lock (and by taking it, prevent session Store from trying to
    call `resolveContactId` before we've crated a contact)

[hf] add docs for running 2 signal installations on 1 device

See merge request !600

[splash] add waitlist notification to how-to guide

See merge request !598

[hotfix] handle signal verification codes with or without hyphens

See merge request !595

[#493] modify identity store to store one identity key per contact

Closes #493

See merge request !596

- note, in signal-android this is performed by:
  - calling `archiveAllSiblings` (to archive all sessions than the
    session with the same device id as the `SignalProtocolAddress`
    provided by the caller) in the body of `#saveIdentity`... IFF
    that call performed an update to a new key.
    - see: `TextSecureIdentityStore#saveIdentity`
  - then archiving the session for the device corresponding to the
    address provided by the caller IFF the `#saveIdentity` call
    performed an udpate
    - see:  `IdentityUtils#saveIdentity`
- we can accomplish this more cleanly/efficiently by simply archiving
  all the sessions at the same time IFF a given call to
  `#saveIdentity` performs an update. so we do that!