web: define integration enroll step event types

[flyinghermit]

This PR:

• adds INTEGRATION_ENROLL_KIND_AWS_IDENTITY_CENTER to IntegrationEnrollKind enum, which is used to identify integration types in the posthog events.
• adds integration enroll step type, which can be used to emit individual configuration step events. Types are immediately used in https://github.com/gravitational/teleport.e/pull/5853 but generic enough to be reused in other integration types.

Type values matches as defined in the proto type #51082

Part of https://github.com/gravitational/teleport.e/issues/5513

[gzdunek]

What would you say for defining this type as a discriminated union?

Suggested change

	export type IntegrationEnrollStepStatus = {
	code: IntegrationEnrollStatusCode;
	error?: string;
	};
	export type IntegrationEnrollStepStatus =
	| {
	code: Exclude<
	IntegrationEnrollStatusCode,
	IntegrationEnrollStatusCode.Error
	>;
	}
	| {
	code: IntegrationEnrollStatusCode.Error;
	error: string;
	};

This has some benefits over the optional field:

1. The error is now required for the error status code.
2. It prevents passing the error for non-error status codes.

Then I'd change the emitEvent signature to:

export function emitEvent(
  eventId: string,
  step: IntegrationEnrollStep,
  status: IntegrationEnrollStepStatus
)

[flyinghermit]

I like it + makes the input param types stronger. Many thanks for the suggestion ade358d

[gzdunek]

I think this comment should be placed in a line above.

[ravicious]

LGTM, but I'm curious about mapping to integers instead of strings. That's based entirely on a single time where I had to do something similar in the Web UI, so I'm not sure if my assumptions are correct.

[ravicious]

Wouldn't you want these to match enum values instead, as in integers? I assume the web API is going to return those integers, not string values, maybe that assumption is wrong.

[flyinghermit]

I did such integer definition when I previously added events but after working in the discover components, I appreciated the shorter name by defining it this way IntegrationEnrollStep.ConnectOidc vs IntegrationEnrollStep.INTEGRATION_ENROLL_STEP_AWSIC_CONNECT_OIDC . The conversion to the integer happens in the web api where we convert it to the proto type.

Though the best way to do is to definitely defining exact 1:1 enum name and value. If this was auto generated *.pb.ts, I would have lived with the longer name but hand defining them lets us do some conversion in the backend and save us from looong name.

[ravicious]

Same here wrt to how this is mapped to the proto enum.