### Description

Currently async_search get or status response include the following info about async_search:

```
  "is_partial" : true, 
  "is_running" : true, 
  "start_time_in_millis" : 1583945890986,
  "expiration_time_in_millis" : 1584377890986,
```

In Kibana we would also like to have something like `completion_time` that would indicate time when the search was completed. It doesn't have to be precise, having some margin of error would be fine. 

**Some context:**

Currently Kibana uses background tasks to monitor completion of searches and it saves the completion time and then later shows it to users when they restore the search. Now we are simplifying the implementation of searches restoration on Kibana side and removing search monitoring in background tasks [(RFC here)](https://docs.google.com/document/d/1xpvW0xHmdm6w6EyYzYd01JLhiPFWF1Ij-tcJxCRLO7U/edit#) so Kibana can't longer track on its side the completion time. 

x-pack/plugin/async-search/src/main/java/org/elasticsearch/xpack/search/MutableSearchResponse.java
clusters
        );
    }
    /**
     * Creates an {@link AsyncSearchResponse} based on the current state of the mutable response.
     * The final reduce of the aggregations is executed if needed (partial response).
     * This method is synchronized to ensure that we don't perform final reduces concurrently.
     * This method also restores the response headers in the current thread context when requested, if the final response is available.
     */
    synchronized AsyncSearchResponse toAsyncSearchResponse(AsyncSearchTask task, long expirationTime, boolean restoreResponseHeaders) {
        if (restoreResponseHeaders && responseHeaders != null) {
            restoreResponseHeadersContext(threadContext, responseHeaders);
        }
        SearchResponse searchResponse;
        if (finalResponse != null) {
            
            searchResponse = finalResponse;
        } else if (clusters == null) {
            
            searchResponse = null;
        } else {
            /*
             * Build the response, reducing aggs if we haven't already and
             * storing the result of the reduction so we won't have to reduce
             * the same aggregation results a second time if nothing has changed.
             * This does cost memory because we have a reference to the finally
             * reduced aggs sitting around which can't be GCed until we get an update.
             */
            InternalAggregations reducedAggs = reducedAggsSource.get();
            reducedAggsSource = () -> reducedAggs;