SurfaceView: Fix overlocking of mSurfaceLock

mSurfaceLock is used to ensure the Surface object stays valid over
the span of the calls to lockCanvas and unlockCanvasAndPost which could
come from any thread. In API Level 29 and below, updateSurface was
split in to two paths, a first path (which would acquire mSurfaceLock)
for when the Surface could be destroyed, and second path for geometry
updates only. The consolidation of these two paths in updateSurface
created an overlocking of mSurfaceLock, which is now acquired even
when mSurface won't be modified. In fact it's acquired whenever the
geometry changes. This means an application rendering thread which
creates delays between lock and unlock canvas could create undesirable
and needless delays on the main UI thread, if the SurfaceView geometry
updates. We also have some underlocking, where we aren't actually
locking when destroying the SurfaceView.

Test: Manual with test app
Bug: 206846658
Change-Id: Idc17d111eee7a7365af4e94a156e7c46c7ea8171