In some error cases, a warning is repeated many many times. It turns out
there is code checking against elasticsearch error codes, and warning
_each_ time it fails to match aganst one of them.
Many times, the error that is being compared is not from elasticsearch,
and in any case, the [elasticsearch-exceptions](https://www.npmjs.com/package/elasticsearch-exceptions)
module is 3 years old. We should rewrite most of this code and stop
using that module.
For now, this at least reduces log noise.
This header is only relevant if dealing with authentication via cookies
or other methods in HTTP requests. The Pelias API intentionally doesn't
deal with authentication at all, assuming anyone who wants
authentication will deal with it using a service placed between Pelias
and end users.
Additionally the CORS spec [does not allow](https://developer.mozilla.org/en-US/docs/Web/HTTP/Access_control_CORS#Credentialed_requests_and_wildcards)
specifying this header while setting a wildcard for
`Access-Control-Allow-Origin`, so it can cause problems in some cases.
Fixes https://github.com/pelias/api/issues/971
Fallback and interpolation queries rely on several results coming back
from Elasticsearch to ensure the best result is returned. It was
possible that queries with `size=1` would not return enough results from
Elasticsearch. This change ensures even with `size=1` a sufficient
number of results are returned.
Fixes https://github.com/pelias/pelias/issues/562
because we have to treat the `city` value as a possible `borough` when not supplied, both `borough` and `locality` results must be preserved when no `borough` is explicitly supplied. For example, `city=Manhattan` must preserve both the borough of Manhattan in New York and the locality of Manhattan in Kansas.