adapter: support mock LaunchDarkly connection

[aalexandrov]

Interpret values of launchdarkly-sdk-key / MZ_LAUNCHDARKLY_SDK_KEY that can be parsed as a socket address as an indication to configure LaunchDarkly to work against a polling address sitting behind http://{url}/polling.

This can be used to provide overrides in CI tests without depending directly on LaunchDarkly. Note that hopefully at some point the Rust SDK will catch up with other languages and we will be able to use this feature and won't need to run a mock LD server process.

Motivation

• This PR adds a feature that has not yet been specified.

Exploring another solution of #25924

Tips for reviewer

To test this, first start a mock LaunchDarkly server (1):

bin/pyactivate -m materialize.ld_mock -l 127.0.0.1 -p 9000

and then environmentd with a custom MZ_LAUNCHDARKLY_SDK_KEY (2)

MZ_LAUNCHDARKLY_SDK_KEY=127.0.0.1:9000 MZ_CONFIG_SYNC_LOOP_INTERVAL=30s bin/environmentd

If there is an easy way to make (1) available to (2) in mzcompose I think we could fix the issue described in #25924 with a more general, single *.py extension in a single place.

Checklist

• This PR has adequate test coverage / QA involvement has been duly considered.
• This PR has an associated up-to-date design doc, is a design doc (template), or is sufficiently small to not require a design.
• If this PR evolves an existing $T ⇔ Proto$T mapping (possibly in a backwards-incompatible way), then it is tagged with a T-proto label.
• If this PR will require changes to cloud orchestration or tests, there is a companion cloud PR to account for those changes that is tagged with the release-blocker label (example).
• This PR includes the following user-facing behavior changes:

[aalexandrov]

Closing in favor of #25950.