[ML][CI] fix integration test after change in ml-cpp#327

[hendrikmuhs]

fix integration test after change in ml-cpp#327

fixes: #36258

[elasticmachine]

Pinging @elastic/ml-core

[droberts195]

The more I look at this the more I wonder whether elastic/ml-cpp#327 was really the right thing to do.

The date_histogram aggregation returns bucket timestamps that are the start of each bucket, which is what the ML C++ used to do for all result types too. So why was there an offset in what was displayed on the chart? Maybe it's because the aggregation used to get the raw data was using an offset in the date_histogram config, but the query to plot the model plot line wasn't? If that's the explanation then an alternative fix would have been to also use an offset when getting the model plot values to plot.

If we stick with the approach of changing the results then I think a docs change is required too. https://www.elastic.co/guide/en/elasticsearch/reference/current/ml-results-resource.html says:

The timestamp for the results is the start of the bucket time interval.

That sentence needs changing to:

The timestamp for the results is the start of the bucket time interval, except for model plot and forecast results generated by version 6.5.3 and above, where the timestamp is the mid-point of the bucket time interval.

I also wonder if this difference in result timestamps for different types of results for the same bucket is going to bite us in some other obscure way, like if there's some other place in the code where we're assuming that we can get all the results relating to a particular bucket with a query that asks for the exact bucket time.

Sorry to bring this up after elastic/ml-cpp#327 is already merged. I should have looked at that more closely when it was in progress.

cc @tveasey @peteharverson @sophiec20

[droberts195]

Following elastic/ml-cpp#332 this PR is no longer required. Once elastic/ml-cpp#332 is backported to 6.5.4 and has propagated through the build system I'll open a new PR to revert the @AwaitsFix.