[Security Solution] Get rid of the OrUndefined types

[banderror]

Background: #132409 (comment)

Summary

We use an OrUndefined pattern when typing various rule parameters:

export const index = t.array(t.string);
export type Index = t.TypeOf<typeof index>;

export const indexOrUndefined = t.union([index, t.undefined]);
export type IndexOrUndefined = t.TypeOf<typeof indexOrUndefined>;

However, while it's useful to create types for most of the parts of a domain model (for both primitive types like Index here and complex data structures like RelatedIntegrationArray) to be able to trace their usage in the codebase,

• Whether a value can be undefined or null or combined with any other type depends on the context (usage). It seems to be more natural to define it in the place where it's used.
• Typescript allows making all properties X | undefined or X | null etc in bulk - no need to create N special types for that. It should be possible to do the same with io-ts.
• No OrUndefined types means less code to write, export, and import. Should be good for the compiler.
• The original type (like Index) can be annotated with a jsdoc comment.

Let's move away from this OrUndefined pattern, delete the OrUndefined types and values, and clean up the remaining types like that:

/**
 * An array of index patterns of a rule.
 */
export type Index = t.TypeOf<typeof Index>;
export const Index = t.array(t.string);

This leverages TypeScript's type aliases (notice that the const declaration is the same name as the type) to comment both the variable and the type at the same time. This is a nice little usability perk in the IDE.

Example of a type that sticks to this new pattern:

kibana/x-pack/plugins/security_solution/common/detection_engine/schemas/common/rule_params.ts

Lines 14 to 57 in fb1eeb0

	/**
	* Related integration is a potential dependency of a rule. It's assumed that if the user installs
	* one of the related integrations of a rule, the rule might start to work properly because it will
	* have source events (generated by this integration) potentially matching the rule's query.
	*
	* NOTE: Proper work is not guaranteed, because a related integration, if installed, can be
	* configured differently or generate data that is not necessarily relevant for this rule.
	*
	* Related integration is a combination of a Fleet package and (optionally) one of the
	* package's "integrations" that this package contains. It is represented by 3 properties:
	*
	* - `package`: name of the package (required, unique id)
	* - `version`: version of the package (required, semver-compatible)
	* - `integration`: name of the integration of this package (optional, id within the package)
	*
	* There are Fleet packages like `windows` that contain only one integration; in this case,
	* `integration` should be unspecified. There are also packages like `aws` and `azure` that contain
	* several integrations; in this case, `integration` should be specified.
	*
	* @example
	* const x: RelatedIntegration = {
	* package: 'windows',
	* version: '1.5.x',
	* };
	*
	* @example
	* const x: RelatedIntegration = {
	* package: 'azure',
	* version: '~1.1.6',
	* integration: 'activitylogs',
	* };
	*/
	export type RelatedIntegration = t.TypeOf<typeof RelatedIntegration>;
	export const RelatedIntegration = t.exact(
	t.intersection([
	t.type({
	package: NonEmptyString,
	version: NonEmptyString,
	}),
	t.partial({
	integration: NonEmptyString,
	}),
	])
	);

Todo

• Delete the OrUndefined types and values.
• Refactor the remaining types.

[elasticmachine]

Pinging @elastic/security-detections-response (Team:Detections and Resp)

[elasticmachine]

Pinging @elastic/security-solution (Team: SecuritySolution)

[banderror]

Done in #142950