Send a contact sync request on initial websocket connection, then parse
the response, grab profile keys and store them (not doing anything with
other contact info and avatars yet).
Also fix attachment decryption - was ignoring extra padding at the end
of the buffer, which image formats were fine with but unmarshalling a
protobuf was not..
- Readloop goroutine gets a new request (incoming message), sends to
incoming loop
- Incoming request loop goroutine calls incoming message handler
- Incoming message handler needs group info, sends a WS request
- Sendloop goroutine gets request, sends on WS, stores response channel
in map
- Incoming message handler is blocked waiting on response on it's
response channel
- Readloop gets some other request, tries to send to incoming loop, but
gets blocked on sending to incoming request channel because it's
unbuffered and that goroutine is still blocked waiting on group info
- Server responds with response to group info request, but readloop is
blocked now forever
The fix: give the incomingRequestChan a large (10000) buffer. Now:
- Readloop goroutine gets a new request (incoming message), sends to
incoming loop
- Incoming request loop goroutine calls incoming message handler
- Incoming message handler needs group info, sends a WS request
- Sendloop goroutine gets request, sends on WS, stores response channel
in map
- Incoming message handler is blocked waiting on response on it's
response channel
- Readloop gets some other request and successfully buffers it in the
incoming request channel
- Server responds with response to group info request, readloop is *not*
blocked, and can pass the response down the response channel that the
incoming message handler is blocked on, and it can finish up
- Incoming request loop is free to continue processing incoming requests
Well enough anyway. When the old prekeyDecrypt fails due to null
pointer, fall through to sealedSenderDecrypt, which usually seems to be
able to decrypt it fine
