[sql] Import SQLite 3.17.0.

[sql] Import SQLite 3.17.0.

Ran through the import script in third_party/sqlite/README.Chromium,
including the SQLite test suite.  No new errors observed.

SQLite changes are at http://www.sqlite.org/changes.html , Chromium
previously used 3.10.2.

All patches were applied and the results reviewed to make sure backported
patches were safe to remove, and retained patches were still covering what was
necessary.  I also tried to test the cases which have failed in previous
imports.

Keep fts4 disabled, and also the new fts3 virtual table and unicode61
tokenizer.  Once enabled, these are very hard to disable, and there doesn't
seem to be any pressure to enable them.  Other SQLITE_* flags were reviewed
for applicability, none looked essential.

BUG=701518
Review-Url: https://codereview.chromium.org/2751253002 .
Cr-Commit-Position: refs/heads/master@{#457853}
Committed: https://chromium.googlesource.com/chromium/src/+/b4325a20870946edaecbe18d2ab0e2e9c01911aa

[Scott Hess - ex-Googler, 2017-03-16 00:40:50]

shess@chromium.org changed reviewers:
+ cmumford@chromium.org

[Scott Hess - ex-Googler, 2017-03-16 00:40:57]

OK, so this is the "real" import, where things actually start being used.  I've
copied the 3.17 code into src, and ran the script to generate the amalgamation,
so there's really nothing to review in those two dirs.  I ran the SQLite tests,
and I've done a couple trybot passes, this being the one based on this CL:
   https://codereview.chromium.org/2755803002/
I have to hack it up because of binary files and size constraints in our system.

Anyhow, I think the only thing that can be productively reviewed are the items
in patches/ .  Mostly, those are just nuisance changes (hashes and counts and
git version data from git-format-patch).  I've annotated the actual changes with
color commentary.

https://codereview.chromium.org/2751253002/diff/1/third_party/sqlite/patches/...
File
third_party/sqlite/patches/0003-Modify-default-VFS-to-support-WebDatabase.patch
(right):

https://codereview.chromium.org/2751253002/diff/1/third_party/sqlite/patches/...
third_party/sqlite/patches/0003-Modify-default-VFS-to-support-WebDatabase.patch:70:
+      return SQLITE_NOMEM_BKPT;
The _BKPT versions are coded so that you can set a debugger breakpoint, then
return the non-_BKPT version.  So this this follows the original code, and
shouldn't change the operation of anything.

https://codereview.chromium.org/2751253002/diff/1/third_party/sqlite/patches/...
File
third_party/sqlite/patches/0004-Virtual-table-supporting-recovery-of-corrupted-datab.patch
(right):

https://codereview.chromium.org/2751253002/diff/1/third_party/sqlite/patches/...
third_party/sqlite/patches/0004-Virtual-table-supporting-recovery-of-corrupted-datab.patch:45:
+
This version changed the line such that I was going to have to rewrap it.  This
seems more maintainable.

https://codereview.chromium.org/2751253002/diff/1/third_party/sqlite/patches/...
File
third_party/sqlite/patches/0007-fts3-Interior-node-corruption-detection.patch
(right):

https://codereview.chromium.org/2751253002/diff/1/third_party/sqlite/patches/...
third_party/sqlite/patches/0007-fts3-Interior-node-corruption-detection.patch:39:
rc = FTS_CORRUPT_VTAB;
This was wrong, before, changing FTS_CORRUPT_VTAB to SQLITE_CORRUPT (should have
been SQLITE_CORRUPT_VTAB).  I suspect that at one point the code this is in
switched from SQLITE_CORRUPT to SQLITE_CORRUPT_VTAB and I missed it.  So this
could be noticed by websql, given the right combination of corruption and error
handling, but I think this code has probably never fired and been handled well
anyhow.

[SQLITE_CORRUPT_VTAB is SQLITE_CORRUPT with some extra bits, so any handling
code _should_ be handling both in the same way.]

[michaeln, 2017-03-16 19:31:18]

r/s lgtm

[Scott Hess - ex-Googler, 2017-03-17 19:26:40]

On 2017/03/16 19:31:18, michaeln wrote:
> r/s lgtm

OK, I'm going to go land this, while I still have enough awake time to monitor
it.

Sheriffs: manual landing due to binary files.  I've done trybots on:
      https://codereview.chromium.org/2755803002/
Past imports tended not to show anything for a few weeks, so I'm confident it
won't have problems, but manual landing makes me nervous.

[Scott Hess - ex-Googler, 2017-03-17 19:33:08]

Description was changed from

==========
[sql] Import SQLite 3.17.0.

Ran through the import script in third_party/sqlite/README.Chromium,
including the SQLite test suite.  No new errors observed.

SQLite changes are at http://www.sqlite.org/changes.html , Chromium
previously used 3.10.2.

All patches were applied and the results reviewed to make sure backported
patches were safe to remove, and retained patches were still covering what was
necessary.  I also tried to test the cases which have failed in previous
imports.

Keep fts4 disabled, and also the new fts3 virtual table and unicode61
tokenizer.  Once enabled, these are very hard to disable, and there doesn't
seem to be any pressure to enable them.  Other SQLITE_* flags were reviewed
for applicability, none looked essential.

BUG=701518
==========

to

==========
[sql] Import SQLite 3.17.0.

Ran through the import script in third_party/sqlite/README.Chromium,
including the SQLite test suite.  No new errors observed.

SQLite changes are at http://www.sqlite.org/changes.html , Chromium
previously used 3.10.2.

All patches were applied and the results reviewed to make sure backported
patches were safe to remove, and retained patches were still covering what was
necessary.  I also tried to test the cases which have failed in previous
imports.

Keep fts4 disabled, and also the new fts3 virtual table and unicode61
tokenizer.  Once enabled, these are very hard to disable, and there doesn't
seem to be any pressure to enable them.  Other SQLITE_* flags were reviewed
for applicability, none looked essential.

BUG=701518

Review-Url: https://codereview.chromium.org/2751253002 .
Cr-Commit-Position: refs/heads/master@{#457853}
Committed:
https://chromium.googlesource.com/chromium/src/+/b4325a20870946edaecbe18d2ab0...
==========

[Scott Hess - ex-Googler, 2017-03-17 19:33:11]

Committed patchset #1 (id:1) manually as
b4325a20870946edaecbe18d2ab0e2e9c01911aa.

[findit-for-me, 2017-03-17 19:52:45]

Findit identified this CL at revision 457853 as the culprit for
failures in the build cycles as shown on:
https://findit-for-me.appspot.com/waterfall/culprit?key=ag9zfmZpbmRpdC1mb3Itb...

[Scott Hess - ex-Googler, 2017-03-18 04:28:52]

also clang on Linux i386