V4L2VDA: Fix a few bugs related to Reset() and buffer management.

- If a Reset() arrived before the first Decode(), or, in general, if it
arrived before V4L2VDA requested buffers, it would assume it had already
have allocated buffers and go back to kDecoding before resuming.

Fix this by checking if the buffers are allocated before resuming and go
back to kInitialized state, instead of kAfterReset. This only works because
we also now make buffer allocation an "atomic" operation for the decoder
thread (see below).

- If a Reset() arrived after V4L2VDA had a chance to request buffers, but
before AssignPictureBuffers() and AssignPictureBuffersTask() resulted in
finishing the buffer allocation sequence, ResetTask would call
StopDevicePoll(), assume the buffers were good for reuse, and queue them to
the free output buffer queue. They would still be missing textures though
and not be ready for reuse, but the decoding would continue. Moreover, the
AssignPictureBuffersTask() would re-queue them to the free queue again.

Fix this by simply making the decoder thread wait for AssignPictureBuffers
before continuing decoding. This doesn't have too much perf impact and
should solve some other potential corner cases, similar to the one above.

With this, we don't need the AssignPictureBuffersTask anymore, and can
do everything in AssignPictureBuffers, while the decoder thread waits.

Separately, don't bail out with an error in a situation when we've already
posted a DismissPictureBuffer for a PictureBuffer to the client and cleared
the corresponding metadata, but it has not yet executed in client before
it had a chance to post a ReusePictureBuffer for it back to us.
Verifying that this exact situation occurred however and not a random
picture id was returned is difficult/impossible and not worth it in
general, so just ignore such buffers (they will have been already freed).

Finally, mark all buffers as not in device after streamoff, and not only
those that are known to be in client; V4L2 spec mandates that the device
is to drop ownership of all queued buffers regardless of whether we dequeue
them in this case.

To test these situations:
- enable the ResetBeforeDecode test for V4L2VDA; this tests for Reset()s
before the Decode() with first config info is called;
- add a new ResetAfterFirstConfigChange case to test situations where
Reset() is called immediately after Decode() with first config info, which
tests how VDA handles Reset() after it had a chance to request buffers,
but before receiving them back.

Also, fix ResetBeforeDecode test to work again, as it seems to have been
accidentally broken by the recent refactoring.

Finally, if a stream is shorter than kMaxResetAfterFrameNum, reset in the
middle of it, instead of resetting after first frame arrives.

BUG=319495,chrome-os-partner:21063
TEST=vdatest, MSE tests, seek tests, res switch tests, youtube with &t=1m
R=fischman@chromium.org, sheu@chromium.org

Review URL: https://codereview.chromium.org/151293003

git-svn-id: svn://svn.chromium.org/chrome/trunk/src@248819 0039d316-1c4b-4281-b951-d872f2087c98
SVN changes up to revision 248819