[Security Solution] Onboarding hub page architecture improvements

[semd]

Summary

Context

Due to multiple design and feature changes, the onboarding hub implementation has been increasing in complexity since it was first created for serverless offerings.

There are some dead features in the code, and there is logic that has become outdated and is no longer needed. Making changes has become harder and time-consuming for this reason. Including fixing bugs like this one https://github.com/elastic/kibana/issues/183760

It is necessary to re-think the architecture of this page, remove unnecessary code, and reduce the complexity to have a more maintainable and extensible code.

Proposal

Simplify the implementation assuming the following requirements:

• The page header is static, including the EuiCards displayed, which do not have any of the functionality of regular (body) cards.
• The progress bar is no longer displayed.
• Cards no longer have internal steps.
• All cards belong to a group.
• Cards are collapsed by default unless an explicit URL hash is present.
• Only one card can be expanded at a time.
• Card content components should be lazy-loaded and be fetched only when necessary (expanded).
• Cards can be marked as completed under different criteria, the completed flag must be stored in the local storage.
• Cards can be automatically checked for completion, the ones that define this property need to be checked when:
  • The page is open and the local storage is empty.
  • The card is expanded, regardless of the local storage.
• Cards with actions that are not allowed by the user capabilities should not be visible (or be disabled).
• Cards with actions that are not allowed by the license should not be visible (or be disabled).
• A group with no visible card should not be visible.
• Serverless-specific content should live in the _security_solutionserverless plugin, and we should expose contract apis from the _securitysolution plugin to let them provide the content. The same applies to stateful-specific content.

Declarative approach

It would be extremely helpful to have a clear declarative definition for groups and cards, to control their behavior in the application easily.

Proposal:

This is an initial proposal for the page definition, it may still need to be extended or modified:

enum OnboardingHubCardId {
  // ...
}

interface OnboardingHubCardDefinition {
  id: OnboardingHubCardId;
  title: string; // i18n
  icon: EuiIconType;
  /**
   * Component to render the card
   */
  component: React.ComponentType<{ setComplete: (complete: boolean) => void }>; // use React.lazy() to load the component
  /**
   * for auto-checking completion
   * @returns Promise for the complete status
   */
  isComplete?: () => Promise<boolean>;
  /**
   * Capabilities strings (using object dot notation) to enable the link.
   */
  capabilities?: RequiredCapabilities; // check `x-pack/plugins/security_solution/public/common/lib/capabilities/has_capabilities.ts`
  /**
   * Minimum license required to enable the card
   */
  licenseType?: LicenseType;
}

type OnboardingHubGroups = Array<{
  title: string;
  cards: OnboardingHubCardDefinition[];
}>;

Design

For reference this is the new design

[elasticmachine]

Pinging @elastic/security-threat-hunting (Team:Threat Hunting)

[elasticmachine]

Pinging @elastic/security-threat-hunting-explore (Team:Threat Hunting:Explore)