Revert 260177 "By keeping track of transfer buffer usage (both s..."

Revert 260177 "By keeping track of transfer buffer usage (both s..."

Caused a heap-use-after-free in GLES2DecoderManualInitTest.AsyncPixelTransfers
on Linux ASan+LSan Tests (1):
http://build.chromium.org/p/chromium.memory/builders/Linux%20ASan%2BLSan%20Tests%20%281%29/builds/863


> By keeping track of transfer buffer usage (both sync and async), it is
> possible to reuse an existing transfer buffer earlier than it is today.
> 
> For synchronous uploads, this is done by inserting tokens marking a
> buffer's last usage. If such a token has passed, the buffer can be
> reused.
> 
> For asynchronous uploads, this is done by adding an internal async
> upload token to the GLES2Implementation and GLES2CmdDecoderImpl that
> enumerates all asynchronous uploads. When an upload is completed, the
> token is synchronized with the client which then can free the memory
> associated with the async token.
> 
> The fenced allocator and mapped memory manager gets a callback that is
> used to allow fenced allocator to make the user, in this case
> GLES2Implementation, poll the current async upload token and free any
> associated memory.
> 
> BUG=328808
> 
> Review URL: https://codereview.chromium.org/116863003

TBR=jadahl@opera.com

Committed: https://src.chromium.org/viewvc/chrome?view=rev&revision=260193

[Charlie Reis, 2014-03-28 18:00:31]

Committed patchset #1 manually as r260193 (tree was closed).

[Charlie Reis, 2014-03-28 18:17:51]

This also failed on Linux Tests (dbg)(2):
http://build.chromium.org/p/chromium.linux/buildstatus?builder=Linux%20Tests%...

GLES2DecoderManualInitTest.AsyncPixelTransfers (run #1):
[ RUN      ] GLES2DecoderManualInitTest.AsyncPixelTransfers

GMOCK WARNING:
Uninteresting mock function call - returning directly.
    Function call: Destroy()
Stack trace:

GMOCK WARNING:
Uninteresting mock function call - returning directly.
    Function call: Destroy()
Stack trace:
Found a corrupted memory buffer in MallocBlock (may be offset from user ptr):
buffer index: 0, buffer ptr: 0x43022188120, size of buffer: 264
Buffer byte 228 is 0x00 (should be 0xcd).
Deleted by thread 0x7f6d09d0c8c0