[ML] Show better file structure finder explanations

[jgowdyelastic]

The find_file_structure endpoint is now always called with the explain flag to allows it to show the logical steps it has gone through to produce its results.
These are available in a flyout when analysis has been successful:

They are also displayed when the analysis has failed:

Also converts all simple functional components and non-react utility code to typescript.
More complicated react components have been left as javascript for now.

Also updates the wrapError function used on all of our endpoint errors to allow an optional attributes property to contain the body of the originally throw error.

cc @droberts195

Checklist

Delete any items that are not applicable to this PR.

• 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

For maintainers

• This was checked for breaking API changes and was labeled appropriately

[elasticmachine]

Pinging @elastic/ml-ui (:ml)

[jgowdyelastic]

@elasticmachine merge upstream

[jgowdyelastic]

@elasticmachine merge upstream

[droberts195]

Thanks for doing this. I think it will make it much easier for people to self-diagnose common problems with file uploads, such as CSV files with different numbers of fields on some lines.

[peteharverson]

Really nice new functionality! Left a couple of minor comments, but otherwise LGTM.

[alvarezmelissa87]

Nit - double copyright comments at the top of this file.

[alvarezmelissa87]

This is used for all the server routes - just would like to confirm it works as expected for those and won't have unexpected side effects. From what I can see it looks fine but just want to confirm this was kept in mind when it was updated. Thanks! 😄

[jgowdyelastic]

It's good to question this! I forgot to add a comment about the change I had to make.
I'll update the description now but basically the only way to get additional information in the kibana error response is to add it in an attributes object.
The original code set the whole boom object as the body, this would be turned into a single string message.
From looking through customError in KibanaResponse and in my testing, it appears these two objects result in the same error message.

{
  body: boom,
  ...
}

and

{
  body: {
    message: boom,
 }
  ...
}

So i used the latter to be able to also add an optional attributes object to the body.
i couldn't use

{
  body: {
    ...boom,
 }
  ...
}

as the spread operator corrupted the boom object. Which was the cause of the failing unrelated tests on this PR originally.

[alvarezmelissa87]

Left a small comment but overall LGTM ⚡️

[kibanamachine]

💚 Build Succeeded

• continuous-integration/kibana-ci/pull-request
• Commit: 799a10b

History

• 💚 Build #38854 succeeded 60e2a55
• 💔 Build #38796 failed af3c067
• 💔 Build #38663 failed 8052dd2
• 💔 Build #38648 failed 5585255
• 💔 Build #38537 failed 09c4d8e

To update your PR or re-run it, just comment with:
@elasticmachine merge upstream