Verify config_json round-trip for connector types other than HTTP

[zibuyu1995]

Background

waitForRemote polls after create and update until the remote object matches the configuration for every key the user set, then errors after 60s. Because config_json is free-form, any field the server rewrites would make that comparison never succeed. The resource would exist remotely and sit in state, but apply would fail, and the next refresh would write the rewritten value into state and produce a permanent diff.

What has been verified

Tested against a Dedicated deployment using the examples/data-integration configuration. Connector, action, and rule all round-trip cleanly:

connector  waitForRemote succeeds = true
action     waitForRemote succeeds = true
rule       waitForRemote succeeds = true

EMQX stored every configured value verbatim and rejected an invalid one rather than rewriting it. The projection also correctly ignored extra top-level fields and an extra nested max_retries field returned by EMQX.

What is still unverified

• Only the HTTP connector and action type was exercised. Kafka, MySQL, MongoDB, Redis, and other types have larger schemas.
• The EMQX version was not captured, so the result is scoped to that deployment at that time.

Suggested scope

For each connector type the product intends to support, create from a representative configuration, read it back, and run projectVisibleJSON against the real response. Clean up in Rule, Action, Connector order. See .codex/rules/testing.md for the live-test requirements.

If a type rewrites values, consider making the timeout configurable, polling for existence and status instead of full equality, or treating config_json as authoritative and giving up drift detection on its contents.