Lock Coordination & Safe Rollout Boundaries

Description

Implement the LockCoordinator to enforce safe rollout boundaries across the cluster. Before the SDK applies a newly detected ETag, it must acquire a distributed semaphore lock based on the rolloutLimit and rolloutKey (defaulting to os.hostname()). Critically, the SDK must completely bypass this locking mechanism during the initial application boot to prevent deployment deadlocks. Furthermore, once a lock is successfully acquired during a hot-reload phase, the SDK must perform a fresh re-fetch of the configuration to ensure it does not apply a stale payload that was superseded while it was waiting in the lock queue.

Acceptance criteria

• The initial configuration fetch during application boot completely bypasses lock acquisition.

• Detecting a change during continuous polling triggers an attempt to acquire a distributed lock before executing onChange.

• If no rolloutKey is provided, the lock defaults to os.hostname().

• Immediately after acquiring a lock, the SDK successfully re-fetches the configuration before passing it to onChange.

Blocked by

Issue #125

User stories covered: 4, 5, 11

Start by reviewing blocked issue #125, then trace the SDK's initial configuration fetch and continuous polling paths that detect ETag changes. Identify where onChange is invoked and where LockCoordinator should sit; done means boot bypasses locking, hot reload acquires the rollout lock, defaults rolloutKey to os.hostname(), and re-fetches configuration before onChange.