[Reporting] Ensure uniform enablement of the plugin

[tsullivan]

Summary

Addresses the first part of #120995

Kibana has safety checks built into the Saved Objects system to ensure that an instance doesn't start if there is an unknown SO type in the data (CHECK_UNKNOWN_DOCUMENTS). This PR gives the Reporting plugin a new saved object type to take advantage of that safety check.

Having a mixed configuration, where Reporting is completely disabled on some instance(s) of Kibana but not others, is not supported because it corrupts the reporting task instances. Today, there is no way for the user to know if they are inadvertently creating that situation - they must resolve the data corruption manually after noticing that Reporting is broken.

Reporting can still be disabled for the most part by setting xpack.reporting.queue.pollEnabled: false in the kibana.yml. This setting does not need to be uniformly set across all Kibana instances.

Checklist

Delete any items that are not applicable to this PR.

• Unit or functional tests were updated or added to match the most common scenarios

[kibana-ci]

⏳ Build in-progress, with failures

• Buildkite Build
• Commit: 0f1b552
• Interpreting CI Failures
• Storybooks Preview

Failed CI Steps

• Jest Integration Tests

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

[pgayvallet]

Kibana has safety checks built into the Saved Objects system to ensure that an instance doesn't start if there is an unknown SO type in the data (CHECK_UNKNOWN_DOCUMENTS).

I'm not sure to fully understand the intent of the PR.

1. Forcefully creating a new SO type just for it to get caught by the unknown doc check if an instance has a specific plugin disabled seems like a misusage of the whole intent of this check to be honest.

2. More importantly, CHECK_UNKNOWN_DOCUMENTS is only performed during a version migration/upgrade. Once the Kibana system indices are migrated, this check is not performed again when a node gets online, so it wouldn't block the user from shutting down a node, disabling reporting, then re-enabling the node, right?

Reporting in Kibana breaks down when the Reporting plugin is disabled on some instances but enabled on others

May we get more info on what exactly breaks when some nodes has reporting enabled and some don't? I'm guessing it's related to task manager somehow?

[tsullivan]

@pgayvallet Thanks for looking at this and helping me understand the capabilities and intent of the "check unknown documents" phase.

May we get more info on what exactly breaks when some nodes has reporting enabled and some don't? I'm guessing it's related to task manager somehow?

Yes - the problem is related to TM. When an instance of Kibana has Reporting completely disabled in config, task manager will mark the stored task instance as "unrecognized" and stop it from running anywhere.

This should have been more clearly answered in #120995. I have updated the issue description to talk about the problem we want to solve.