`Buffer<'_>` shouldn't be `Send`

[madsmtm]

Android holds a lock on the buffer while it's in use, see #331, and I'm experimenting a bit with a similar design on macOS (which is to say, I think it's a reasonable thing for our buffers to do).

MutexGuards are not Send though, which makes me wonder if this is sound?

Is there a use-case for Buffer<'_> being Send? As-in, is there ever a case where you would want to present on a different thread than the one that called next_buffer()? The problem wouldn't exist if you moved the entire Surface to a different thread.

I can see the argument for buffers being Sync though (&mut T is Sync), it could maybe make sense to pass the buffer to a scoped thread and render in that.

[MarijnS95]

There is definitely a case to be made for where you want to send your locked buffer (raw pointer) to another thread for (costly) rendering or pixel processing, while keeping the "main thread" available for processing input events until the update returns?

However I don't know remember if the unlockAndPost() this NativeWindowBufferLockGuard does automatically on drop() is also thread-safe.

OTOH the NativeWindow is Send+Sync so you can always send a clone of it (refcount increment) to another thread to lock()+render+drop() (unlockAndPost()) there already.

EDIT: unlockAndPost() doesn't take an argument which buffer. So I guess whenever you call lock() twice, the thing either crashes or deadlocks. ASurfaceControl/ASurfaceTransaction is the more appropriate way forward but only available in a functional way since API level 34 (I wish I put my branch in a draft PR already for keeping track).