DO NOT MERGE: Move blast sync handling to BBQ

Add logic in BBQ so it can handle waiting the transaction callback vs a
sync transaction request. The following behavior will occur

1. If a nextTransaction (sync) was set, we will wait until the
transaction callback for that frame before continuing to acquire
new frames. Once the transaction callback for the sync transaction is
invoked, BBQ will flush the shadow queue. It will try to process
as many frames as it can that were queued up during the time BBQ was
blocked from processing.

2. If BBQ is waiting on a sync transaction callback and then another
sync transaction is requested afterwards, BBQ will allow it to acquire
a buffer instead of just adding to the shadow queue. It will acquire
the new frame in the new sync transaction and allow the caller that
requested the sync to apply it. At this point, it's up to the callers
to ensure they apply the two sync transactions in order to ensure
frames are applied in order.

3. Similar to 2, but if there are queue requests in between the two
sync requests that aren't trying to be synced. When the second sync
frame is getting acquired, BBQ will acquire and release any frames
that were requested in between. This is so we don't skip or
have to wait in the first sync transaction callback.

Test: BLASTBufferQueueTest
Bug: 200285149
Change-Id: I8da8de1a3fe2a44ca2199ff92cfd4b60c7f01183
(cherry picked from commit d7deef7278f934a1750738b600c11c1771ae7ac6)

0 files changed, 0 insertions, 0 deletions