Remove task to cleanup action_task_params of failed tasks

[mikecote]

Part of #79977 (step 2).
Resolves #79977.

In this PR, I'm removing the recurring task defined by the actions plugin that removes unused action_task_params SOs. With the #152841 PR, tasks will no longer get marked as failed and we have a migration script (excludeOnUpgrade) that removes all tasks and action_task_params that are leftover during the migration https://github.com/elastic/kibana/blob/main/x-pack/plugins/actions/server/saved_objects/index.ts#L81-L94.

NOTE: I will hold off merging this PR until #152841 is merged. (merged)

To verify

Not much to test here, but on a Kibana from main there will be this task type running in the background and moving to this PR will cause the task to get deleted because it is part of the REMOVED_TYPES array in Task Manager.

[elasticmachine]

Pinging @elastic/response-ops (Team:ResponseOps)

[mikecote]

@elasticmachine merge upstream

[mikecote]

@elasticmachine merge upstream

[mikecote]

@elasticmachine merge upstream

[mikecote]

Moving PR back to draft, the previous PR (#152841) caused a lot of flaky tests that I will focus on first.

[mikecote]

@elasticmachine merge upstream

[mikecote]

@elasticmachine merge upstream

[mikecote]

@elasticmachine merge upstream

[kibana-ci]

💚 Build Succeeded

• Buildkite Build
• Commit: 237bce3

Metrics [docs]

Unknown metric groups

ESLint disabled line counts

id	before	after	diff
securitySolution	433	436	+3

References to deprecated APIs

id	before	after	diff
actions	35	34	-1

Total ESLint disabled count

id	before	after	diff
securitySolution	513	516	+3

History

• 💔 Build #116055 failed a180b60
• 💛 Build #115982 was flaky 99fd832
• 💔 Build #115957 failed f406235
• 💛 Build #115746 was flaky 01b5055
• 💔 Build #115701 failed 1fdf616

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

cc @mikecote

[pmuellr]

Reviewed the code, looked good, so tried a migration from 8.2.3 to this PR.

Weirdly, it looks like it migrated task manager in place - I know that's a new thing now, but since we did have migrations between then - adding the enabled field at least - I figured it wouldn't do it in place. But it did!

Here's _cat alias for TM indices:

.kibana_task_manager       .kibana_task_manager_8.2.3_001 - - - -
.kibana_task_manager_8.8.0 .kibana_task_manager_8.2.3_001 - - - -

So, the odd-ball thing is that the old task that SHOULD HAVE been deleted, is still there. With an enabled flag of true - so I know it got migrated. That seems to indicate some issue with us "removing" tasks during these "in place" migrations. At least I was expecting it to be deleted.

Thinking we should have someone else repro this, and if it's not me "holding it wrong", open an issue to get the "removed tasks" bit working again ...

[pmuellr]

code LGTM; Kibana survived a migration from 8.2.3, but I left a comment in the PR because it turns out it didn't actually delete the old task (which I was expecting) - not a bug in this code though, so approving :-)

[pmuellr]

Reading through the "REMOVED_TYPES" processing in task manager, it looks like we don't actually delete the docs, we just don't search for them anymore. So I guess, working-as-designed? Seems weird to have enabled task docs in the index, that won't be read, based on a list of task types in the code. I wonder whether we should somehow make more explicit in the docs themselves, that they are no longer in use, if we're going to keep them around.

[mikecote]

Good observation, @pmuellr! I created #153964 to discuss the oddity now that we are using REMOVED_TYPES more, so we can discuss if we'd like to do anything further. The original PR adding REMOVED_TYPES can be found here: #123963, basically we fixed the issue where tasks would get marked as unrecognized too soon and would have to re-create the task to have it working again. Deleting the task seems like a fair next step to investigate 👍