Avoid deadlock in EventThread::onNewVsyncSchedule

EventThread::onNewVsyncSchedule attempts to lock mMutex, but it is
currently called while Scheduler::mDisplayLock is held. But
shouldConsumeEvent is called while mMutex is locked, and
shouldConsumeEvent's call to mThrottleVsyncCallback results calls
Scheduler::isVsyncValid, which then calls multiple methods that require
locking mDisplayLock, resulting in deadlock.

MessageQueue::onNewVsyncSchedule runs into a similar problem. It is also
called while mDisplayLock is held.

Split up the calls to onNewVsyncSchedule into a separate method, which
is called after mDisplayLock is released. Create
promotePacesetterDisplayLocked, which returns the new pacesetter's
VsyncSchedule so it can be applied afterwards. This avoids the deadlock.

In addition, handle the connections the same as other calls: lock
mConnectionsLock, store a pointer to the EventThread, and call the
method after releasing the lock. This is safe because Scheduler never
deletes its EventThreads (until its own teardown).

Bug: 272943830
Test: manual (see b/272234280)
Change-Id: Ieb05fc3abcf4fc20f04ea5d3595da70155de2df5