[ML] Use doc links service for transforms

[lcawl]

Summary

Related to #86036

This PR replaces documentation links in the transform pages with calls to the documentation link service, so that the links are all maintained in one place.

[lukeelmers]

Is the intent for apis to be a general grouping of docs for all ES REST APIs? Asking because I want to make sure we know what belongs here moving forward.

Transforms have their own section, which feels a bit inconsistent, so I guess I'm wondering if we should consider something like this:

docLinks.links.transforms.putTransform
docLinks.links.indices.createIndex

Or perhaps group all ES docs generally like this:

docLinks.links.es.guides.transforms
docLinks.links.es.apis.transforms.putTransform

Either way I'm not too concerned about this ATM -- we really need to rethink how this service works anyway and it isn't difficult to change -- just thought I'd ask in case anyone has thoughts on it.

[lcawl]

At this point, my idea was that the apis grouping would contain reference material for APIs from any product or solution. In the near future, we're moving away from product-focused documentation, but we'll still have (hopefully auto-generated) reference pages for Kibana, Elasticsearch, and Cloud APIs, for example. I've added more examples in #86972. If it's preferable to include the API links under feature groupings, I'm okay with that, though I'm not sure what feature we'd put things like the "create pipeline API" under. An "ingest" grouping? Happy to consider whatever additional reorganization suggestions you have.

[lukeelmers]

my idea was that the apis grouping would contain reference material for APIs from any product or solution. In the near future, we're moving away from product-focused documentation, but we'll still have (hopefully auto-generated) reference pages for Kibana, Elasticsearch, and Cloud APIs, for example.

Thanks, this is helpful context -- in that case the grouping makes a bit more sense to me.

I'm not sure what feature we'd put things like the "create pipeline API" under. An "ingest" grouping? Happy to consider whatever additional reorganization suggestions you have.

Yeah I don't necessarily have an answer to this ATM either, I suppose I was mostly trying to get a picture of what you had in mind.

It seems like it would be worth revisiting this discussion and re-evaluating how docLinks is structured further down the road, once the new docs are in place.

[elasticmachine]

Pinging @elastic/ml-ui (:ml)

[peteharverson]

LGTM

[lcawl]

@elasticmachine merge upstream

[kibanamachine]

💚 Build Succeeded

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

Metrics [docs]

Async chunks

Total size of all lazy-loaded chunks that will be downloaded as the user navigates the app

id	before	after	diff
transform	1.0MB	1.0MB	-1.0KB

Distributable file count

id	before	after	diff
default	47266	48026	+760

Page load bundle

Size of the bundles that are downloaded on every page load. Target size is below 100kb

id	before	after	diff
core	560.8KB	560.9KB	+171.0B

History

• 💚 Build #96477 succeeded 7befcf7
• 💚 Build #96222 succeeded 82efc13cead12e0e6d620fa16156b31f8b2a37a8
• 💔 Build #96215 failed 51cc77f6c40ef9e8bfc0d6012a91902c29cf75a7

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