Add mInterfaceLock back to Camera3Device methods called by RequestThread.

Methods like reconfigureCamera called by the RequestThread internally
call methods which might expect to have mInterfaceLock locked
(eg: configureStreamsLocked).

Also, function calls which expect to be serialized w.r.t
reconfigureCamera can cause reported camera status to be inconsistent
w.r.t the expected status.

For example the following situation might occur
through CameraTest.java#testVideoSnapshot :

For certain video sizes that would fail to configure the camera
startRecordingL
    camera reconfiguration is triggered -> reconfigureCamera() starts
    waitUntilDrained -> gets interleaved with reconfigureCamera()
    reconfigureCamera() completes
    Here the status of the camera device is active instead of CONFIGURED.
    updateRecording
        createStream() called expects the camera to not be in an ACTIVE
        state since updateProcessorStream cannot handle stream
        configuration failure gracefully when the device is streaming.
        However since waitUntilDrained did not complete after
        reconfigureCamera the camera status is STATUS_ACTIVE.

As a result, we should hold mInterfaceMutex while
calling these methods. To avoid deadlocks (b/143513518), we can have the thread
calling disconnect, relinquish mInterfaceMutex right before it starts
waiting on RequestThread to exit. It can re-acquire it when
RequestThread finishes.

Bug: 147313521

Test: atest CameraTest.java#testVideoSnapshot on pixel2 passes
Test: camera CTS
Test: GCA (sanity)

Change-Id: I384f62bc9936d9691dfe9c13ff743e3d07f2ed55
Signed-off-by: Jayant Chowdhary <jchowdhary@google.com>