refactor highlight.run SDK into plugins

[Vadman97]

Summary

Refactors the highlight.run SDK into plugins that can be connected to the 3.x and 4.x LaunchDarkly SDKs.

import { initialize } from '@launchdarkly/js-client-sdk'
import Observability, { LDObserve } from '@launchdarkly/observability'
import SessionReplay, { LDRecord } from '@launchdarkly/session-replay'

const client = initialize('client-side-id-123abc', {
	plugins: [
		new Observability('highlight-project-id', {
			networkRecording: {
				enabled: true,
				recordHeadersAndBody: true,
			},
			otlpEndpoint: 'https://otel.observability.ld-stg.launchdarkly.com',
		}),
		new SessionReplay('highlight-project-id', {
			networkRecording: {
				enabled: true,
				recordHeadersAndBody: true,
			},
			backendUrl: 'https://pub.observability.ld-stg.launchdarkly.com',
		}),
	],
})

How did you test this change?

local testing with react-router app, new unit tests

validating bundling working as expected (@launchdarkly/observability does not bundle rrweb, @launchdarkly/session-replay bundles observability features since it uses them and rrweb)

Are there any deployment considerations?

0.x versions of @launchdarkly packages released.
changeset for highlight.run

Does this work require review from our design team?

no

[kinyoklion]

Things should work with launchdarkly-js-client-sdk 3.x as well, correct? Or did you find something lacking in the interfaces?

[Vadman97]

Things should work with launchdarkly-js-client-sdk 3.x as well, correct? Or did you find something lacking in the interfaces?

tested with 3.x: helped find a bug because the 0.6.0 @launchdarkly/js-client-sdk sdk version didn't have the afterTrack implementation

[ccschmitz-launchdarkly]

Very cool! Left a couple thoughts, but will leave the real review to @kinyoklion.

I mainly looked over the observe plugin. I'm sure we don't want to diverge too much from the existing implementation, but was wondering if we wanted to take the opportunity to clean up some of the rough edges, mainly deprecated or poorly chosen config options.

[samstokes]

@Vadman97 Please forgive the comment without context - is application.id the right thing to pass here? I'm not sure if this is just a terminology thing (in LD terms "application" is a separate concept from "environment", but I'm not sure about the Highlight terminology), or if we've arranged for the plugins to pass the LD environment id in the application id field, etc.

Also, fun fact, the LD client-side id is actually identical to the LD environment id, so we might not need to pass both. (The client-side id is also used as a credential - albeit a weird one that's not treated as secret - so it might be better not to include it per se in the telemetry unless we have a good use case for it?)