[Logs UI] Add "Analyze in ML" buttons

[Kerry350]

⚠️ ⚠️ ⚠️ This PR contains all commits from #47642 and #47558 and should not be reviewed / merged until they're merged ⚠️ ⚠️ ⚠️

Summary

This closes #46445 by implementing "Analyze in ML" buttons to the log rate results page. There's a button next to the overall chart, and buttons for the individual partitions.

Implementation notes

I've used chrome.getBasePath() imported from ui/chrome which isn't ideal given the new platform changes. I tried to use our useKibanaInjectedVar hook to access this, but I couldn't seem to get that to work (definitely possible PEBCAK). It works...but not ideal 🙈

Checklist

Use strikethroughs to remove checklist items you don't feel are applicable to this PR.

• This was checked for cross-browser compatibility, including a check against IE11
• Any text added follows EUI's writing guidelines, uses sentence case text and includes i18n support
• Documentation was added for features that require explanation or tutorials
• Unit or functional tests were updated or added to match the most common scenarios
• This was checked for keyboard-only and screenreader accessibility

[elasticmachine]

Pinging @elastic/infra-logs-ui (Team:infra-logs-ui)

[elasticmachine]

💔 Build Failed

• continuous-integration/kibana-ci/pull-request
• Commit: 8d72d24

[elasticmachine]

💚 Build Succeeded

• continuous-integration/kibana-ci/pull-request
• Commit: 1f530d1

[weltenwort]

Both links successfully link to the Single Metric Viewer in the ML UI. I think this is appropriate for the partition-specific inspection link. How about linking to the "Anomaly Explorer" for the overall link instead?

I wonder how useful passing the whole link format function down is. 🤔 In the places where the link is rendered, the dynamic arguments (start, end) are already known. So maybe it would be clearer to move the URL formatting logic to the ML link component and just pass down the jobId? So the component would be something like

<AnalyzeInMlButton jobId={jobId} partition={partition} timeRange={timeRange} />

The button itself would then use the base path from chrome to assemble the link. The partition prop could be optional to switch between the filled overall link and the empty detail link.

Would that make sense?

[Kerry350]

@weltenwort Thanks for the review 👍 I've made all of the changes suggested, this is ready for another look.

[weltenwort]

Looks great, thanks for keeping it so clean under time pressure ❤️

The comment below is just something I remembered taking me a lot of time to debug a while ago.

[weltenwort]

From experience there are situations where the all-mighty angular router chooses to disagree with the standard url encoding. It might be safer to use the QueryString.encode function from ui/utils/query_string to avoid that. Not sure if that is likely to happen here, but encodeURIComponent rings an alarm bell with me. 😉

So it could look something like

const hash = `/timeseriesexplorer?${QueryString.encode({_g, _a})}`;

[Kerry350]

Thank you for the hint, changed 👍 There seems to be quite a lot of discrepancy across all of the different Kibana plugins when it comes to links (understandable to a degree with React vs Angular, but even then even within the same routing environment).

[elasticmachine]

💚 Build Succeeded

• continuous-integration/kibana-ci/pull-request
• Commit: d483ed7

[elasticmachine]

💚 Build Succeeded

• continuous-integration/kibana-ci/pull-request
• Commit: 9dab86d