Work around Mali flips between stale DRI2 buffers

When resizing the screen under a mutter-based environment (causing
a new scanout buffer to be allocated), Mali is inconsistent about what it
does next (possibly depending on the position of the mouse pointer).

Sometimes it does not call GetBuffers immediately so it tries to flip
the old front/back buffers (which have the wrong resolution). This
confuses the state and makes future flips fail. Detect this case
and reject the flip so that subsequent flips work.

Most of the time, after this failed flip, Mail follows up with
GetBuffers and then a good SwapBuffers call, correcting the situation.
However there are also some cases where it only follows up with
GetBuffers and doesn't do a swap, a situation that I've not been
able to find a workaround for. When this happens the screen will be
black until the next update.
Work around Mali use-after-free upon window resizing

Two quick successive resizes of the LibreOffice Writer window under
gnome-shell results in momentary visible corruption.

Inspecting the stream of events, it seems that two successive resizes
with `xdotool windowsize --sync` causes 5 flips to happen. Flip number 2
has bad data. In between flips 1 and 2, Mali asks us to destroy the DRI
buffer backing the window size at first resize, then it calls
CreateBuffer on the window drawable at its second resize, then
ScheduleSwap. Suspicious that it frees the previous window buffer so soon.

We discovered that delaying the freeing of the buffer that we were asked
to destroy makes the corruption go away. Looks like Mali has a
use-after-free bug.

We try to work around this in a simple way: we now delay all bo frees
until the next ScheduleSwap. We've done a few tests to confirm as best we
can that ScheduleSwap is indeed a reliable indication from Mali that it
has finished drawing the scene. This workaround works for the mutter case,
but is likely to fail on multi-display setups, complicated compositors
that render more than one flip in advance, etc.

Thanks to Vincent Sanders and Daniel Stone for help understanding this
issue.