[#466] signalc supports attachments

Closes #466 (closed)

context

• we are bringing signalc up to feature parity with signald before launching
• this MR adds support for sending attachments

changes

configs / tooling

• specify attachments directory (/signalc/attachments) in Config/App
• ensure this dir exists by:
  • mounting it in docker containers
  • including commands to create it in /bin/setup

data model

• add all relevant attachment fields to both SocketRequest.Send.Attachmentand SocketResponse.Ciphertext.Attachment

logic layer

• extend SignalReceiver#handleCiphertext to support attachments:

  • if an attachment is present in a data message:
    • obtain a pointer to the attachment
    • fetch the attachment from the signal cdn into an input stream in a temporary file
    • read the input stream into a permanent file on the signalc file system
    • emit a socket response (to signalboost) containing a filename that points to the atttachment's location on disk

• extend SignalSender#send to support attachments:

  • if the attachments field is non-empty in an incoming socket request, for each attachment:
    • read the filename field on the attachment and use it to locate the file stored to disk above by SignalReceiver
    • open an input stream from that file and pass it to SignalServiceMessageSender to read from and upload to the cdn (encrypted for its new recipient)
    • importantly: do NOT wrap this stream in a use block, as it is important the stream is still open when it is passed to the libsignal message sender!

testing note

• this behavior would be substantially better tested with integration tests against a fake signal server
  • as it stands, the tests must heavily mock out all the I/O behavior that does the real work (confusing to read) and work very hard to make some minimally useful assertions (e.g.: that we actually do write an atttachment to the file system on the receive path or read from it on the send path, that we don't close the input stream before handing it off to libsignal)
  • it would be much simpler (and more cinfidence-boosting) to try to send a file and verify that it was actually received.

misc changes

• we add a standalone FileUtil#readToFile function that is useful in tests and might be useful elsewhere
• we try to use non-blocking file input / output streams where possible, but some of these are created by libsignal and therefore are not under our control (add it to the list of things that might create throughput bottlenecks we should watch for in monitoring)
• we add better stacktrace handling in various error printing scenarios

privacy consideration

• files stored in /attachments dir over time appear to persist there.. we should run a job to delete all attachments older than a day! (see #469 )