fix: mark connector and function user config as sensitive

[david-streamlio]

Fixes #213

Motivation

configs on pulsar_source and pulsar_sink carries arbitrary connector settings, and in practice that is where credentials end up — a JDBC sink needs its password somewhere, and configs is where every other setting for that connector already goes. The attribute is not marked sensitive, so those values are echoed in terraform plan and terraform apply output.

pulsar_function has the same shape in user_config.

This is the enforcement half of #204, which documents the hazard. Documentation alone leaves the value printed to every terminal and CI log that runs a plan.

Modifications

Add Sensitive: true to:

• configs on pulsar_sink (resource_pulsar_sink.go)
• configs on pulsar_source (resource_pulsar_source.go)
• user_config on pulsar_function (resource_pulsar_function.go)

and regenerate docs/.

Scope, and what I deliberately left alone. The issue asks to audit pulsar_function for the same gap, so to be explicit about where I drew the line:

• secrets is not marked sensitive. It holds {"path": ..., "key": ...} references rather than values. Keeping it visible shows which secret names are wired up, which is useful in a diff and is not itself sensitive.
• custom_runtime_options is not marked sensitive. It can carry credentials, but feat(function): expose input_specs for per-topic consumer config #219 is actively changing its structure, and masking it would also hide runtime settings that are usually not secret. Better decided on its own once feat(function): expose input_specs for per-topic consumer config #219 settles.

Trade-off worth naming. Non-secret settings in configs and user_config — a JDBC URL, a table name, a threshold — now render as (sensitive value) in diffs. That is the unavoidable cost of a free-form attribute: the provider cannot tell which keys hold credentials. The issue raises the same concern. If you would rather accept noisier diffs than mask everything, the alternative is to leave configs visible and rely on #204's documentation alone — happy to go that way instead.

Also note this is a mitigation rather than a fix: the value still lives in state, as with any sensitive attribute. Using secrets, so the credential never reaches connector config, function metadata or state at all, remains the stronger recommendation.

Verifying this change

• Make sure that the change passes the CI checks.

This change is already covered by existing tests:

• make test and golangci-lint pass.
• go generate ./... reproduces the committed docs/ output; the only diff is the three attributes gaining the Sensitive marker.
• Acceptance tests run against Pulsar 4.0.3: TestSink, TestSinkUpdate, TestSource and TestFunction all pass, confirming that marking the attributes sensitive does not disturb the read/write paths or state handling.

Documentation

Check the box below.

Need to update docs?

• doc-required

• no-need-doc

• doc

  docs/resources/{sink,source,function}.md regenerated; the three attributes now show as (Sensitive).

[freeznet]

Pushed 7988721 to close the post-#219 sensitivity gap.

Changes:

• mark pulsar_function.sink_config.configs and source_config.configs as sensitive, matching the existing connector configs and function user_config behavior;
• regenerate the function docs;
• add a schema regression test covering both nested blocks.

Validation:

• GOTOOLCHAIN=go1.25.14+auto GOWORK=off go test ./...
• GOTOOLCHAIN=go1.25.14+auto GOWORK=off go vet ./...
• go generate ./...

custom_runtime_options remains unchanged as discussed in the PR scope. As with other Terraform sensitive attributes, the values are redacted from normal CLI output but remain present in Terraform state.