[Reporting/CSV] Make searches used for export inspectable

[tsullivan]

Clear and simple error messages aren't helpful in some cases with automated reports. We are able to add error messages and warnings from Elasticsearch into the report job metadata, but with automated reports the only artifact the end user handles often is the report content itself.

1. CSV Reporting should handle the following condition: a search request to Elasticsearch fails with an error and there is no data to collect. In this condition, we should put the failure error into the report contents itself. This will ease troubleshooting that can be very difficult today when reports are generated with Watcher.

2. We should raise diagnostic info out of the debug logs, by giving the user a way to "replay" the query in Dev Tools/console. This would improve triaging CSV issues when the root cause is performance issues with ES, as it gives a way to reproduce the hits on performance without creating a report. (Thanks to @sebelga for this idea.)

[elasticmachine]

Pinging @elastic/appex-sharedux (Team:SharedUX)

[petrklapka]

@tsullivan - if this would lead to SDH reduction, could be a good candidate for Reporting Scaling work package.

[tsullivan]

Updated the description: increased the scope by adding the requirement for a button to replay the queries in Dev Tools/Console.

[tsullivan]

In this condition, we should put the failure error into the report contents itself. This will ease troubleshooting that can be very difficult today when reports are generated with Watcher.

Adding this content turns out to be technically infeasible due to how the contents of the report come directly from the hits.hits section of the ES query response.

I'm focusing on the suggestion to have a "Open in Console" button visible on the report info side panel. This will yield the best user experience when they face performance with search performance, to eliminate the possibility the problem is in the CSV Reporting layer of the platform.