don't use a spinlock for the HandleArena

We've seen hangs/ANR that are not well understood on that spinlock, so
for now we're going back to mutexes, which, on android, are very 
efficient under low contention (no syscall).

FIXES=[308029108]

filament/backend/include/private/backend/HandleAllocator.h

@@ -239,14 +239,16 @@ class HandleAllocator {
         }
     };
 
-
+// FIXME: We should be using a Spinlock here, at least on platforms where mutexes are not
+//        efficient (i.e. non-Linux). However, we've seen some hangs on that spinlock, which
+//        we don't understand well (b/308029108).
 #ifndef NDEBUG
     using HandleArena = utils::Arena<Allocator,
-            utils::LockingPolicy::SpinLock,
+            utils::LockingPolicy::Mutex,
             utils::TrackingPolicy::DebugAndHighWatermark>;
 #else
     using HandleArena = utils::Arena<Allocator,
-            utils::LockingPolicy::SpinLock>;
+            utils::LockingPolicy::Mutex>;
 #endif
 
     // allocateHandle()/deallocateHandle() selects the pool to use at compile-time based on the

filament/src/details/Engine.h

@@ -487,7 +487,7 @@ class FEngine : public Engine {
     ResourceList<FRenderTarget> mRenderTargets{ "RenderTarget" };
 
     // the fence list is accessed from multiple threads
-    utils::SpinLock mFenceListLock;
+    utils::Mutex mFenceListLock;
     ResourceList<FFence> mFences{"Fence"};
 
     mutable uint32_t mMaterialId = 0;