Fix queue event lifecycle on googlevr and noapi platforms

[MortimerGoro]

GLSurfaceView.queueEvent() calls dispatched before the surfaceView renderer is ready are dispatched before the activityCreated callback is notified to native. This can cause some nullptr device states (we had to add a if not null workaround) or issues when initializing some data (e.g curdved setting on the first widgets created)

[bluemarvin]

Looks good, but rather than locking maybe just ensure the queue code is only called on the main UI thread?

[bluemarvin]

Are events getting queued off of the main UI thread?

[MortimerGoro]

queueRunnable is always called from the main thread. But the pendingEvents array is iterated also when the surfaceCreated callback is received to notify the pending events

[MortimerGoro]

I did some tests removing the lock and adding this to onSurfaceCreated:

PlatformActivity.this.runOnUiThread(() -> {
  mSurfaceCreated = true;
  notifyPendingEvents();
});

But we hit a deadlock on Daydream. runOnUiThread is never executed because onPause is waiting for a runnable being ran in the GLThread.

[bluemarvin]

Would it make more sense to use the same queue we use on the other platforms and just stop using the GLView’s queue?

[MortimerGoro]

I think it's a good idea for consistency. I'll run some tests

[MortimerGoro]

I did some tests on this branch: 3af65da (adapted for Daydream only)

Found two problems:

• We can't correctly dispatch onDestroy() using the vrb::Queue because SurfaceView is already stopped in onPause. Tried with surfaceView.queueEvent only for that method, it works because the thread underlying thread is still alive.
• On the next run after a destroy there is a deadlock in onPause(). Not sure why yet...

Using the lock solution of this PR the life cycle seems good, onDestroy is correctly dispatched and next run after a destroy runs ok.