This adds support for custom boosts to the addressit-style search
queries. The newer libpostal based queries do not include this
functionality since they can only query for addresses.
By definition, all boundary.country query matches will either be
identical, or not a match. Thus, it does not make sense to put the query
clause for boundary.country in the `must` section of the query.
In theory, because our queries would generally combine this `must`
clause with others, there shouldn't be any performance improvement (or
regression) from this change.
However, semantically, this clause fits better as a `filter`, and in the
case of a bug causing a degenerate query with the `boundary.country`
query clause as the only one under the `must` section, this would have a
big impact.
This query extends the standard focus query view with hardcoded layers
for which the query applies. The intent was to apply the focus scoring
only to non-admin areas, but the list of layers was already out of date,
as it was missing streets.
The query is fundamentally problematic with custom layers as well.
This lowers the autocomplete focus boost from 40 to 15. The idea is
that, because the boost for population is 20, the focus can't possibly
override a popular city, but it can come close.
On our default dev build, no acceptance tests fail but the san francisco
autocomplete test now passes!
It's not clear if this fixes WOF venue issues yet, since the latest
build there failed :(
adjusted tests to account for new querying strategies, renamed all existing test fixture files to `*_original`. pointed query module to a PR for testing.
This was missed by me when working on https://github.com/pelias/api/pull/580, but caught by the acceptance tests!
Unfortunately it was caught after going to production.
OSM data includes two almost identical 'Keskustori, Tampere' entries.
The second one does not have additional 'name.ru' property. This is
no longer considered as a difference in deduping.