GitLab

[hotfix] actually send broadcast messages in sequence

See merge request !387

* we introduced a fix a long time ago to send broadcast messages in sequence
  on the theory that (1) this would jam up signald's concurrency bugs
  less and (2) we had observed health checks fail less and transmit
  faster when sent in sequence
* however, we did not notice that `broadcastMessage` was only ever
  being called with one recipient (presumably to get per-recipient
  language choices honored) so we were never actually sending such
  messages in sequence
* @mari has a more comprehensive fix coming in #329, but until it
  lands, here is a small patch to make sure broadcast messages
  actually go out in sequence so we can measure if this makes any kind
  of difference in perf/reliability

[hotfix] notify maintainers on the diagnostics channel

See merge request team-friendo/signalboost!386

* we used to notify ourselves on BOOST IT, now we tend to get
  notifications on `DIAGNOSTICS`. let's be consistent about that!
* while at it: send these notifications in sequence. if a big channel
  is destroyed or recycled, we don't want signald to shit the bed
* aaaand... let's make `_notifyMany` handle either a concrete message
  or a notification key so we can use it as a helper for all of our
  notify functions

[hotifx] don't notify maintainers about eventless recycle jobs

See merge request team-friendo/signalboost!385

Resolve "admins can undo recycle"

Closes #215

See merge request team-friendo/signalboost!384

* was sending destruction notification in default lang (EN) to all recipients
* should send notification in reach recipient's lang
* to fix, provide new impl of `notifyMembersExcept`

* calls an async function repeatedly on an interval
* returns a function that, if invoked, cancels the next call of the
  async function

* the `common.destroy` function is odd
  * accepts a nullable channel (instead of just not being called)
  * has a funny return signature
  * the fact that it is a method on a channel rather than a function
    call that accepts a channel (or phone number) forces some tightly
    coupled testing patterns (that could be cleaner with pure functions
    on the db) without saving any db queries by doing so
* replace it with `channelRepository.destroy` and also create
  `phoneNumberRepository.destroy`: leaves cleaner test seams and less
  convoluted branching logcis
* clean up tests for destroy that (1) break b/c of this, (2) were
  tightly coupled and a bit hard to follow/change anyway

* get (classified) mature requests
* recycle the unredeemed channels
* notify admins of redeemed channels that their channel won't be recycled
* notify admins of all results (redemption/recycle/recycle-error)

* find all the requests issued before the start of the grace period, indicating
  channels which should be considered for recycling (b/c their grace
  period has passed)
* make lists of redeemed and unredeemed channel phone numbers, where
  "redeemed" channels have been used since the start of the grace
  period, and thus should not be recycled
* return them to the caller for processing (ie: we will defer actual
  recycling to the `registrar` level)

* rename `enqueueRecyclablePhoneNumber` to `requestRecycle`
* refactor it a bit to streamline (eliminate db call & extra
  conditional by leveraging `findOrCreate` semantics in repository layer)
* move it to the `registrar.phoneNumber.recycle` module
* elimininate the `registrar.phoneNumber.enqueRecycle` module

* fix failing unit tests
  * while at it: inline and clean up some stub helpers (decouple find
    stubs from destroy stubs)
* refactor for modularity
  * extract `registrar.phoneNumber.common.destroyChannel` to channel repository
  * extract `notifyMembers`/ `notifyAdmins` to `registrar.phoneNumber.common`

* rename from `recycleablePhoneNumberRepository` to `recycleRequestRepository`
* only expose one method: `requestToRecyle`, which finds or creates a
  recycle request for a given phone number

[#296] Resolve "suggest adding channel name to signal contacts in welcome message"

Closes #296

See merge request team-friendo/signalboost!383