Omnibox: HistoryQuick Should Only Index & Search First 1k of URL & Title

Makes HistoryQuick provider only index the first 1k charcters in a URL
and the first 1k characters in a title.  This should save speed and
memory because the index will be smaller and faster to search when
users have long URLs in them.

I don't imagine there will be an quality impact because who searches
for a URL using characters so deep in the URL or the title?  I'm
so comfortable with this that I want to launch it without running an
omnibox experiment.

I bumped the HistoryQuick provider cache version number to enforce
that everyone rebuilds their cache.  This will let me easily look at
statistics about cache size and HQP speed before and after this change.
(Without bumping the cache version number, users will rebuild their
cache weekly, but I will not be able to easily tell which users have
rebuilt and which users have not, and hence cannot do a simple before/after
comparison.)

Tested to verify that HQP still seems to work.  Also tested that it
solves the lagginess described in the listed bug.

TBR=sky

BUG=281461

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

git-svn-id: svn://svn.chromium.org/chrome/trunk/src@236776 0039d316-1c4b-4281-b951-d872f2087c98
SVN changes up to revision 236776
Omnibox: Don't Let Users Escape Keyword Mode Accidentally

The current code already protects against users escaping keyword
mode accidentally in regular (non-reorder mode).  This change
simply adds the proper annotations so reorder mode has the
protection as well.

There are three parts to this change:
* Mark navsuggestions as "not allowed to be default match" if the
user is in keyword mode.  Revise tests to reflect this.
* Add a constraint that, in keyword mode, there must be at least
one keyword (query) suggestion that be the default match.  Restore
the keyword verbatim if the constraint is violated.  Revise tests to
reflect this.
* As a post-processing step, if there is at least one keyword mode
match that can be default [1], mark all matches from other sources
(e.g., the default search engine) as not allowed to be the default
match.  Revise tests to reflect this.

[1] Given the second bullet (the constraint), you might wonder why
it could be the case that there might not be a keyword mode match
that can be default.  The reason for this criteria is that the
user could be in keyword mode for a keyword extension or some
such thing, but we can't trust KeywordProvider to always make a
default match in those cases.  For instance, the extension could be
disabled.  Hence, we maintain the invariant that SearchProvider always
returns a match that can be default, even if needs to back off to
the default provider match to do so.


By the way, the regular mode protection works as follows:
(i) demote all navsuggestions past the score of the top query
when in keyword mode
(ii) abandon suggested relevance scores on the default provider,
meaning the top result from the default provider will score 250
when in keyword mode
(iii) enforce a constraint that a match (thus implicitly a keyword
mode match) must score at least 850

Together, these constraints (and the way it fixes the violations)
guarantee that a query from the keyword provider comes first in regular
(non-reorder mode).

BUG=317946,318543

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

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