Reverse the order of slowlog's source and X-Opaque-Id attributes #71557
Description
Hello!
Currently, in search slow log, the X-Opaque-Id header is appended as the last element of the message string right after the query's source attribute. Given the fact that in the ESJsonLayout layout there's no control over the message size, there's no guaranty that the X-Opaque-Id header will exist in the slow log's output for applications that generate big queries in size. Moreover, since there's no way currently to disable the search slow log's source similar to the index slow log, if you want to parse the message (let's say via a grok pattern) in order to visualize the queries via a Kibana index, you can't achieve the desired behavior due to the fact that the id field may have been trimmed completely from the slow log making the X-Opaque-Id header a noop for those queries.
I suppose that simply reverting the order in which those entries are appended to the search slow slog could easily fix such issues. Furthermore, ensuring that the biggest slow log entry (aka source) is always the last element in the message string would protect us from similar inconsistencies in the future, in case a probable field addition will be made in the slow log message.
Note that while looking for existing/similar issues I've stumbled upon this PR (#52507) which is idle (and closed) for almost a year now. Since I couldn't figure out the reason it was abandoned, I chose to open a feature request for that, since that would indeed be a really valuable modification on the search slow log functionality.