feat: add X-LaunchDarkly-Instance-Id header to server SDK (SDK-2353)

[keelerm84]

Summary

Adds the X-LaunchDarkly-Instance-Id header to every outbound polling, streaming, and event request from libs/server-sdk. Value is a v4 UUID (via boost::uuids::random_generator, the same generator already used by asio_event_processor for X-LaunchDarkly-Payload-Id) generated once per SDK instance and stable for that instance's lifetime.

The UUID is generated in ClientImpl's constructor and stamped onto base headers alongside user-agent, authorization, and x-launchdarkly-tags.

Design note (worth a reviewer's attention)

The UUID is generated in ClientImpl ctor rather than in HttpPropertiesBuilder::Build() because Build() is called twice on the same logical SDK instance (once during ConfigBuilder::Build, again during ClientImpl construction when authorization/user-agent are layered on). Generating in Build() would produce two different UUIDs per SDK instance, violating the "constant throughout the lifetime" requirement.

Scope

libs/server-sdk only. The shared HttpPropertiesBuilder in libs/common is untouched; the analog work for libs/client-sdk is intentionally out of scope.

Test plan

• Added unit tests in libs/server-sdk/tests/instance_id_test.cpp: UUID v4 format check (regex on 4xxx/[89ab]xxx variant bits), 100-sample uniqueness, header-name constant, client construction smoke test
• Registered "instance-id" capability in contract-tests/server-contract-tests/src/main.cpp
• CI will be the first run of the full build. Local machine is missing Boost dev headers and ninja, so cmake + tests were not executed locally. Please double-check CI output carefully.

---

Note

Low Risk
Scoped wire-contract header in server-sdk only; generation is isolated and covered by unit and contract tests, with no auth or data-path changes.

Overview
Adds X-LaunchDarkly-Instance-Id on outbound server SDK HTTP traffic (polling, streaming, and events) so SCMP server-connection-minutes can attribute requests to a single SDK process.

A new MakeInstanceId() helper produces a v4 UUID (Boost random_generator, thread-local). The value is set once when ClientImpl builds shared HttpProperties—not inside HttpPropertiesBuilder::Build(), because config and client each call Build() and a second UUID would break the “stable for this instance” rule.

libs/common and client-sdk are unchanged. Contract tests advertise capability instance-id; instance_id_test.cpp covers format, uniqueness, header name, and client construction.

^{Reviewed by Cursor Bugbot for commit 9ecdc7e. Bugbot is set up for automated code reviews on this repo. Configure here.}

[kinyoklion]

Suggested change

	// boost::uuids::random_generator emits a version 4 (random) UUID, which is
	// what the SCMP spec requires. The generator carries state (an internal
	// RNG), so constructing it on every call is fine for our use case where we
	// only call MakeInstanceId once per SDK instance.
	static thread_local boost::uuids::random_generator generator;
	// boost::uuids::random_generator emits a version 4 (random) UUID, which is
	// what the SCMP spec requires. The generator carries state (an internal RNG
	// seeded from system entropy on construction), so we cache it per thread to
	// avoid redundant entropy draws on repeated calls.
	static thread_local boost::uuids::random_generator generator;

[keelerm84]

Done -- updated the comment to your wording in 9ecdc7e.

[kinyoklion]

Suggested change

* See: sdk-specs / SCMP-server-connection-minutes-polling.

[keelerm84]

Done -- removed the spec reference line in 9ecdc7e.

[kinyoklion]

Approved pending comment changes.