GitLab

[477] fix prekey bundle bug

Closes #477

See merge request !577

- now there is only signalc (which is the pinned variant)

- restore distinction between CIPHERTEXT and PREKEY_BUNDLE in SignalReceiver
- always decrypt all incoming messages (even dropped ones) so that we
  properly handle PREKEY_BUNDLE responses (we think!)

[splash] add Matrix community room to splash about page

See merge request !576

[#465] Resolve "load: identify choke point in signalc send path"

Closes #465

See merge request !562

- Add prometheus client, add Metrics prom object, instrument SignalSender with histograms.
- Add metrics for SocketSender.
- Add prometheus metrics, add custom thread Dispatcher, fix bottleneck.
- Change libsignal service maven source to our 0xacab registry.
- Add Metrics to Application in order to facilitate mocking, make Metrics non optional to libsignal.
- Change all coroutines to use one global thread pool.

[#473] signalc: respond gracefully to shutdowns

Closes #473

See merge request !574

- we want to avoid `rm -f` (which would short circuit our graceful
shutdown sequence!)

- leave 120sec for drain, 125sec before SIGKILL
- leave these timers exposed as env vars so we can change them
  on the fly without redeploy (if we ever discover our timeout is too
  short and we are not draining messages fast enough, we likely want
  to change that ASAP)

- we were using both a stub-able inner singleton method and a config toggle to
  turn off actually exiting the process
- since we *need* the stub-able inner singleton method to assert that
  exit was called, let's *only* use that and get rid of the toggle
  intended to disable editing in test environment
- since this was our only toggle, we also now get rid of the `toggles`
  config value (for now)

- extract shared `drain` logic to `logic.MessageQueue`, which consumes
  an atomic counter, timeout, and poll interval passed by
  caller (in this case, `SignalSender` and `SignalReceiver`)

justification:
- caching envelopes adds db calls to our already db-constrained critical send
  path
- it also doesn't likely deliver much value, since we spend most of
  our time in shutdown waiting for the send queue to drain (which
  would take MUCH longer than the amount of time we can imagine
  waiting to decrypt incoming messages)
- as a hedge against the possibility, we will add logic to drain the
  receive queue as part of the shutdown task...
- meantime, we will delete this in one atomic commit, so that we can
  repurpose the envelope-driven logic later when/if we need to
  serialize envelopes as part of the Canopy design (to store envelopes
  while the protocol store is "locked" so we can replay them and
  process them once the store becomes "unlocked")

(had mistakenly added them to the splash site setup script!)