[#401] signalc: handle expiry time changes

Closes #401 (closed)

context:

• signalc is meeting perf specs so we are trying to bring it to feature parity with signald (handling all request types we send to it from signalboost) before shipping
• this MR implements handling of expirty time changes

changes

signalc

handling expiry time changes:

• implement SocketReceiver#setExpiration, which handles a SocketRequest.SetExpiration message off the socket by constructing a SignalService.DataMessage of type ExpirationUpdate and using the SignalServiceMessageSender to send it to the account (admin/subscriber) with whom we wish to update expiry timers for a given channel account

using an existing expiry time:

• request handling: add expiresInSeconds as a required field on SocketRequest.Send JSON messages
• in signal-sender: pass this value to SignalSender#send instead of a default value
• in signal-receiver: allow (and relay) empty ciphertext messages, since this is how incoming expiry time updates will look to signalboost channels

signalboost

• pass whatever is stored as a channel's messageExpiryTime value as the expiresInSeconds field on every single message we send over signal
  • this requires refactoring sdMessageOf to have an expiresInSeconds field (which defaults to 1 week if none provided)
  • it also requires all callers of signal.send to provide an expiry time, and -- most interestingly -- for welcome messages to explicitly state that they would like to not disappear by setting expiresInSeconds to 0
• note: this design is fundamentally different than signald, which omits the expiresInSeconds field from ciphertext messages because it stores the state of expiry timers within signald's "contact store" and then appends them to messages before sending them. this requires both (1) keeping a "contact store" in the first place, and (2) making an extra call to the persistence layer for state that may be provided bythe caller. (our solution thus (1) does not require signalc to have a contacts store -- yay! -- and (2) is stateless w.r.t. expirty timeer in each #send call, both of which seem better suited to our use case

code health side-effects

fix thread starvation in tests:

• symptom: socket server tests do not open connections
• cause: there are no threads available to open new sockets on b/c prior tests have consumed them and not released them
• fix: use a cached thread pool to back the dispatcher used in the TestSocketClient coroutines

drop annoying ExperimentalTime annotations:

• we used to have to decorate almost every class in the app with this annotation (including lots of ones that did not use the featuer) simply b/c we used it in one method call (SocketReceiver#subscribe) to time exponential backoff retries
• this was annoying and confusing1
• instead we just use Longs (noting they stand for for millis in a comment) and get rid of all the stray annotations!