Check File snapshots and Blob byte counts when writing to IDB

Check File snapshots and Blob byte counts when writing to IDB.
This also fixes a few bugs in the IDB/Blob stuff:
* Removed a DCHECK that could hit depending on test teardown order.
* Made ChainedBlobWriterImpl truly asynchronous, fixing a crash if a File write failed before the first Blob write was attempted.
* Fix a crash where we'd try to free a scoped_ptr twice in the event of an abort.

Note that most of the time we won't actually receive File metadata, as Files often aren't snapshotted; I've got a blink change in progress [https://codereview.chromium.org/325383002/] that will always send it.

BUG=

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

[jsbell, 2014-06-18 23:26:10]

lgtm (but cmumford should take a look too)

https://codereview.chromium.org/333533002/diff/100001/content/browser/indexed...
File content/browser/indexed_db/indexed_db_backing_store.cc (right):

https://codereview.chromium.org/333533002/diff/100001/content/browser/indexed...
content/browser/indexed_db/indexed_db_backing_store.cc:2329: // The round-trip
can be lossy; round to nearest millisecond.
This is because we've asked the filesystem for the time on the exact same file
before, but are storing it in a different type, correct? It's unrelated to the
filesystem's precision, etc?

[ericu, 2014-06-18 23:28:44]

https://codereview.chromium.org/333533002/diff/100001/content/browser/indexed...
File content/browser/indexed_db/indexed_db_backing_store.cc (right):

https://codereview.chromium.org/333533002/diff/100001/content/browser/indexed...
content/browser/indexed_db/indexed_db_backing_store.cc:2329: // The round-trip
can be lossy; round to nearest millisecond.
On 2014/06/18 23:26:10, jsbell wrote:
> This is because we've asked the filesystem for the time on the exact same file
> before, but are storing it in a different type, correct? It's unrelated to the
> filesystem's precision, etc?

I believe that's the case.  I've hit this before in Chrome code, and verified
earlier today that I saw an error on the order of a microsecond.

[ericu, 2014-06-19 18:47:15]

On 2014/06/18 23:28:44, ericu wrote:
>
https://codereview.chromium.org/333533002/diff/100001/content/browser/indexed...
> File content/browser/indexed_db/indexed_db_backing_store.cc (right):
> 
>
https://codereview.chromium.org/333533002/diff/100001/content/browser/indexed...
> content/browser/indexed_db/indexed_db_backing_store.cc:2329: // The round-trip
> can be lossy; round to nearest millisecond.
> On 2014/06/18 23:26:10, jsbell wrote:
> > This is because we've asked the filesystem for the time on the exact same
file
> > before, but are storing it in a different type, correct? It's unrelated to
the
> > filesystem's precision, etc?
> 
> I believe that's the case.  I've hit this before in Chrome code, and verified
> earlier today that I saw an error on the order of a microsecond.

Chris, I'll be checking email now and then today and tomorrow; I'd like to try
to get this in well before the branch point if possible.

[cmumford, 2014-06-19 19:37:54]

lgtm

https://codereview.chromium.org/333533002/diff/100001/content/browser/indexed...
File content/browser/indexed_db/indexed_db_dispatcher_host.cc (right):

https://codereview.chromium.org/333533002/diff/100001/content/browser/indexed...
content/browser/indexed_db/indexed_db_dispatcher_host.cc:653: if (info.size !=
static_cast<uint64_t>(-1)) {
Just curious why IndexedDBMsg_BlobOrFileInfo.size is unsigned?

[ericu, 2014-06-19 21:00:04]

https://codereview.chromium.org/333533002/diff/100001/content/browser/indexed...
File content/browser/indexed_db/indexed_db_dispatcher_host.cc (right):

https://codereview.chromium.org/333533002/diff/100001/content/browser/indexed...
content/browser/indexed_db/indexed_db_dispatcher_host.cc:653: if (info.size !=
static_cast<uint64_t>(-1)) {
On 2014/06/19 19:37:54, cmumford wrote:
> Just curious why IndexedDBMsg_BlobOrFileInfo.size is unsigned?

IIRC it's a remnant of the WebKit API; we might want to make it just an int64
like it is elsewhere.

[ericu, 2014-06-19 21:00:36]

The CQ bit was checked by ericu@chromium.org

[commit-bot: I haz the power, 2014-06-19 21:02:19]

CQ is trying da patch. Follow status at
 https://chromium-status.appspot.com/cq/ericu@chromium.org/333533002/100001

[commit-bot: I haz the power, 2014-06-19 22:30:17]

Change committed as 278509