Support ObjectName UID version (v1/v3/v4) for agent self-identity

Background

The Pinpoint Java Agent generates the agent's self-identity (ObjectName) in one of three formats — v1 / v3 / v4 — based on the pinpoint.modules.uid.version setting. This issue ports the same capability to the C++ Agent.

Configuration property

• Key: UidVersion (env: PINPOINT_CPP_UID_VERSION)
• Allowed values: v1, v3, v4 (case-insensitive); default v3; unknown/missing → v3
• v4-only: ServiceName (PINPOINT_CPP_SERVICE_NAME), ApiKey (PINPOINT_CPP_API_KEY)

Version differences

v1 and v3 are identical on the wire (protocol.version=100); the only difference is the applicationName length limit (24 vs 254).

Requirements

• Parse UidVersion / ServiceName / ApiKey (YAML + env), with default/fallback handling
• ID validator (charset [a-zA-Z0-9._-], per-version length constants)
• v1/v3/v4 resolver — abort startup (noop agent) with a log when a required value is missing
• UUIDv7 generation (RFC 9562) + URL-safe Base64 encoding (22 chars, byte-compatible with Java Base64Utils)
• gRPC header builder version branching (protocol.version, plus servicename/apikey for v4)
• Mask apiKey in logs / serialization
• Unit tests: version parsing, length boundaries (24 vs 254), v4 missing-required-value, UUID→base64 golden vectors, per-version header sets

Notes: corrections vs. the Java spec

• protocol.version wire value is 100 / 400 (ProtocolVersion.V1(1_00) / V4(4_00))
• The start-time header key is starttime (matches the existing C++ value)
• v4 regenerates the agentId (UUIDv7) on every restart (same as Java)

Start by locating the existing C++ configuration parsing, ObjectName/agentId resolution, and gRPC header-building paths. Trace their current tests, then cover version parsing, validation, UUID-to-Base64 vectors, required v4 values, masked ApiKey handling, and the per-version header sets until all listed boundaries pass.