feat: deprecate FDv2 payload filter builder methods

[beekld]

Deprecates the FDv2-specific PayloadFilter builder methods, since payload filtering is not supported with the FDv2 data system.

Closes SDK-2972, part of SDK-2575.

• PollingDataSourceBuilderV2.PayloadFilter and StreamingDataSourceBuilderV2.PayloadFilter now carry a Deprecated: note pointing at the FDv1 equivalents.
• No behavior change: the methods still work, and the FDv1 builders (including FDv1PollingDataSourceBuilderV2, used for FDv1 fallback) are untouched.
• Removal (and dropping the dataSystem.payloadFilter wiring in the test service) is left for a follow-up once the contract test harness no longer sends that field.

Implementation details

The contract test harness removed the FDv2 payload filter scenarios (launchdarkly/sdk-test-harness#431), so the public FDv2 filter surface is going away across SDKs. This PR is the deprecation step only, keeping the change non-breaking; the test service still maps DataSystem.PayloadFilter into these builders, which is why they aren't removed yet.

Doc-comment-only change, so no new tests. Verified with go build ./..., go vet ./..., make lint (0 issues) and go test ./ldcomponents/....

Link to Devin session: https://app.devin.ai/sessions/ed604c6db94d452ea9f2dc35d6acc398
Open in Devin Desktop: https://app.devin.ai/desktop/session/ed604c6db94d452ea9f2dc35d6acc398?variant=devin
Requested by: @beekld

---

Note

Overview
FDv2 polling and streaming data source builders now treat PayloadFilter as deprecated: godoc notes that payload filtering is unsupported on the FDv2 data system and the methods will be removed later.

On Build, configuring any payload filter (including an empty string) no longer returns an error for ""; instead the SDK logs a warn that filtering is not supported and will stop being applied in a future release. Filter values are still passed through to the underlying config for now.

Tests for both builders were updated to expect success with an empty filter and to assert the deprecation warning is emitted only when a filter is set.

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

[devin-ai-integration]

🤖 Devin AI Engineer

I'll be helping with this pull request! Here's what you should know:

✅ I will automatically:

• Address comments on this PR. Add '(aside)' to your comment to have me ignore it.
• Look at CI failures and help fix them

Note: I can only respond to comments from users who have write access to this repository.

⚙️ Control Options:

• Disable automatic comment, CI, and merge conflict monitoring

[keelerm84]

I wonder if we shouldn't move this comment towards the top for better visibility, particularly since this function effectively does nothing.

For SDKs that make it easy, we should also log a warning if they are using these methods. Most SDKs won't have a logger in the builder, so we may want to look at logging somewhere post construction.

[devin-ai-integration]

Both done in e39874d:

• Moved the Deprecated: paragraph directly under the summary line on both builders, so it's the first thing you see (godoc/gopls pick it up anywhere in the doc comment).
• Go's builders do get a logger at Build time, so Build now logs a warning when a filter key was set: "Payload filtering is not supported with the FDv2 data system; the configured payload filter will stop being applied in a future release". Added unit tests for the warning being present/absent.

Worth noting the filter is still applied today — the warning says it will stop being applied, since removal comes in the follow-up. For SDKs without a logger in the builder I'll do the same thing at construction time where possible.

[keelerm84]

Since payload filters don't do anything on fdv2, maybe this shouldn't be an error any more? We can just silently ignore the empty string because it was never going to do anything anyway?

[devin-ai-integration]

Agreed — done in 3075cef. Both V2 builders now just warn whenever a filter was set (empty or not) and no longer return an error, and I dropped the "cannot be an empty string" line from the streaming doc comment. Tests updated to expect success. The FDv1 builders keep the validation.