Undo accidental changes to indexed_db/docs/README.md

In https://chromium-review.googlesource.com/c/chromium/src/+/1955823 the
code was updated to match the terminology in the readme (blob key vs blob
number), however in doing so accidentally the readme was also modified.

This reverts the changes to the readme, as it already used the correct
terminology for blob numbers and blob keys.

Bug: 1027737
Change-Id: Ie4012688901b9813248e99bce93ee6b454eba53e
Reviewed-on: https://chromium-review.googlesource.com/c/chromium/src/+/1993872
Commit-Queue: Marijn Kruisselbrink <mek@chromium.org>
Commit-Queue: Daniel Murphy <dmurph@chromium.org>
Auto-Submit: Marijn Kruisselbrink <mek@chromium.org>
Reviewed-by: Daniel Murphy <dmurph@chromium.org>
Cr-Commit-Position: refs/heads/master@{#729948}

content/browser/indexed_db/docs/README.md

@@ -75,27 +75,27 @@ A blob number is a `int64_t` number that is unique and auto-incrementing per
 database in an origin. This is used to uniquely identify a blob in an IndexedDB
 database.
 
-#### Blob Number
-A blob number is a `int64_t` `database_id` and a unique auto-incrementing
+#### Blob Key
+A blob key is a `int64_t` `database_id` and a unique auto-incrementing
 `int64_t` `blob_number`. The database metadata contains a
-`BlobNumberGeneratorCurrentNumber` which is used to save the next blob number number
+`BlobNumberGeneratorCurrentNumber` which is used to save the next blob key number
 to use.
 
-A blob number uniquely identifies a blob in an backing store.
+A blob key uniquely identifies a blob in an backing store.
 
 ####  Blob File
 A blob file is the physical file stored on disk that represents a **persisted**
 blob. It resides in the following directory:
 `IndexedDB/<serialized_origin>.blob/<database_id>/<blob_number>`
-Note that `database_id` + `blob_number` is a unique blob number.
+Note that `database_id` + `blob_number` is a unique blob key.
 
 A blob that has been **persisted** in the database is stored in a blob file.
 This file is deleted when the blob is **unlinked** and **inactive**.
-(Technically this is done by adding the corresponding blob number is added to the
+(Technically this is done by adding the corresponding blob key is added to the
 recovery journal, which is processed every once in a while to delete unused
 files).
 
-There is a 1:1 mapping between a blob file and a blob number.
+There is a 1:1 mapping between a blob file and a blob key.
 
 #### Blob Handle
 This is-a `storage::BlobDataHandle` OR a `blink::BlobDataHandle` OR a
@@ -116,7 +116,7 @@ and keeps it alive in the blob system.
 #### Blob Entry
 A blob entry contains a vector of blob infos that are **persisted** in the
 database. All of these blob infos, at least initially, do not have a blob
-handle, and only contain the blob number & blob file information (like size, type,
+handle, and only contain the blob key & blob file information (like size, type,
 time modified, etc).
 
 A Blob Entry is a value that is saved into the database using a `BlobEntryKey`:
@@ -128,17 +128,17 @@ A `BlobEntryKey` is used as a key in the leveldb database and contains the
 given object store data key.
 
 #### Recovery Journal
-The recovery journal is a list of blob numbers that are pending deletion. These
-blob numbers represent blobs that are in an **unlinked**, **inactive**, and
+The recovery journal is a list of blob keys that are pending deletion. These
+blob keys represent blobs that are in an **unlinked**, **inactive**, and
 **persisted** state.
 
 This is used to maintain consistency if a crash occurs or if there is an error
 while committing a transaction. The recovery journal is "processed"
 intermittently when there isn't an active transaction. Processing means that
-every blob file referenced in the journal (by the blob number) is deleted, and the
+every blob file referenced in the journal (by the blob key) is deleted, and the
 journal is cleared.
 
-The recovery journal is where all blob numbers that are to-be-deleted by a
+The recovery journal is where all blob keys that are to-be-deleted by a
 transaction are placed. (They are subsequently immediately deleted after the
 transaction is committed, but this can fail / crash so they are placed in the
 journal first).