Split the lock synchronizing LMKD socket reads/writes

Current locking mechanism in LmkdConnection which synchronizes socket
reads and writes with socket destruction and replacement can result in
a deadlock because both read and write synchronize on the same lock.
That creates a possibility of a deadlock if the data pipe between AMS
and LMKD is full. AMS sends data to LMKD and blocks until LMKD reads
older data from the pipe to free some space for the new data. LMKD
is busy sending data to AMS and also blocks until AMS read some data
from its end of the pipe. AMS is trying to read the data from LMKD but
blocks because send operation is holding the lock they both are
synchronized on.
Change this synchonization mechanism to use two separate locks, one for
reads and one for writes so that concurrent send and receive can succeed
while preventing concurrent modifications to the socket itself.

Bug: 349702703
Google: 3157258
Change-Id: Icd4b9a2862bca8f18e213cf216d019231e0dbd2f