ES API errors bubble up to `no_search_results_array`, hiding the error code/details

#### Context

I'm working on a plugin to customizes ES Search results, and have setup callbacks for `jetpack_search_abort` and `failed_jetpack_search_query`, in order to log problems.

I don't have a paid plan setup for the site yet, so the WPCOM API returns a HTTP `403` with a body of `{"error":"Unauthorized","message":"The plan for {blog id} does not allow access to ES search."}`. I'd assume that would also happen in situations where a paid plan fails to renew, because of an expired credit card, etc. I'm guessing the problem I describe below would happen for other types of errors as well.

#### Problem

There are a couple things that seem wrong with the error handling in `Jetpack_Search`, but the symptom I'm seeing is that the details of failed requests are being obscured.

When `search()` sees the unsuccessful response, it returns a new `WP_Error` to `do_search()`:

https://github.com/Automattic/jetpack/blob/e13487d0dbbe4c743739b6f1a3e37c143a8c2614/projects/plugins/jetpack/modules/search/class.jetpack-search.php#L446-L448

A few lines lower in `search()`, though, the response code is checked again (even though it hasn't changed), and `failed_jetpack_search_query` is triggered. I don't think that code path can ever execute, because of the early return above.

https://github.com/Automattic/jetpack/blob/e13487d0dbbe4c743739b6f1a3e37c143a8c2614/projects/plugins/jetpack/modules/search/class.jetpack-search.php#L486-L505

When `do_search()` sees the returned `WP_Error`, it returns early.

https://github.com/Automattic/jetpack/blob/e13487d0dbbe4c743739b6f1a3e37c143a8c2614/projects/plugins/jetpack/modules/search/class.jetpack-search.php#L666-L673

Because of that, `filter__posts_pre_query()` fires `jetpack_search_abort` with the `no_search_results_array` error code.

https://github.com/Automattic/jetpack/blob/e13487d0dbbe4c743739b6f1a3e37c143a8c2614/projects/plugins/jetpack/modules/search/class.jetpack-search.php#L528-L534

Because of that, the only information about the failure that `jetpack_search_abort` callbacks will receive is the `no_search_results_array` code, and a message saying `Invalid response from API - 403`, which doesn't give the details necessary to fix the error.

A similar problem may exist in the Instant Search class, but I haven't checked.

#### Potential Solution

* The lowest-hanging fruit is to just add the response details as the 3rd argument to the `WP_Error()` instantiations, so that the actual error details make it to the action callbacks. _i.e., the (misnamed) `$request` var for the first `WP_Error`, and `$response` for the second `WP_Error`._
* Ideally though, it seems like the function should be refactored so that `failed_jetpack_search_query` is triggered instead of (or maybe in addition to) `jetpack_search_abort`.

This was previously worked on in https://github.com/Automattic/jetpack/pull/14594, but the fix was reverted in https://github.com/Automattic/jetpack/pull/14624. It seems like the plan was to re-introduce it, but that never happened? cc @mjangda , @jeherve

Start in projects/plugins/jetpack/modules/search/class.jetpack-search.php and trace search(), do_search(), and filter__posts_pre_query() through the referenced error paths. Review the earlier pull requests #14594 and #14624 before choosing between preserving response details and changing the callback behavior; done means failed API responses expose actionable error information to the relevant callbacks.

Written by the indexing model from the issue text.