cameraserver: fix deadlock scenario in torchModeStatusChanged callback.

The following scenario can occur:

T1: CameraService::connectDevice()
      CameraService::connectDeviceHelper()
         CameraProviderManager::openSession() ---> holds mInterfaceLock
         .
         .
         . on the same thread before openSession execution completes
           CameraProviderManager::ProviderInfo::torchModeStatusChange() callback from HAL
           .
             CameraService::onTorchStatusChanged()
               CameraProviderManager::getSystemCameraKind tries to lock mInterfaceLock -> deadlock.

We now pass in system camera kind to onTorchStatusChanged in
CameraProviderManager::torchModeStatusChange() instead of calling getSystemCameraKind

This CL also removes CameraProviderManager::mStatusListenerMutex, since
it wasn't protecting any data structure.

Bug: 202198748

Test: camera CTS, GCA (basic validity)

Change-Id: Id95a2aa061b6cb4db4a25b1a2aa6a390f898af87
Signed-off-by: Jayant Chowdhary <jchowdhary@google.com>
diff --git a/services/camera/libcameraservice/tests/CameraProviderManagerTest.cpp b/services/camera/libcameraservice/tests/CameraProviderManagerTest.cpp
index a74fd9d..c8a6b32 100644
--- a/services/camera/libcameraservice/tests/CameraProviderManagerTest.cpp
+++ b/services/camera/libcameraservice/tests/CameraProviderManagerTest.cpp
@@ -274,6 +274,8 @@
             hardware::camera::common::V1_0::CameraDeviceStatus) override {}
     void onTorchStatusChanged(const String8 &,
             hardware::camera::common::V1_0::TorchModeStatus) override {}
+    void onTorchStatusChanged(const String8 &,
+            hardware::camera::common::V1_0::TorchModeStatus, SystemCameraKind) override {}
     void onNewProviderRegistered() override {}
 };