TTL does not go back to default when going from specified -> null

[Morganamilo]

Problem

Removing message_ttl from an ably_rule_amqp_external target does not revert the queue to its default TTL. The value set at creation persists, contradicting the documented behaviour that leaving the field empty uses the queue default.

Context

The provider vendors its own Control API client, and the field is MessageTTL *int with omitempty (control/types.go:411). The provider leaves it nil when the attribute is null or unknown (internal/provider/rules.go:271-275), and omitempty then drops messageTtl from the request body entirely, so the Control API is never told to change it and keeps the previous value.

The read path has matching behaviour: internal/provider/rules.go:604-605 treats a returned TTL of 0 as null, so zero and unset are already the same thing to the provider.

Clearing therefore needs the request to say something rather than nothing, and which representation the Control API accepts for "use the queue default" needs confirming: an explicit null, an explicit 0, or a dedicated unset. Whether the Control API supports any of them is the first thing to establish, because if it does not, the fix is server-side and this ticket becomes about surfacing that rather than fixing it in the provider.

This is a Unito mirror of GitHub issue 149, also tracked as SDK-2978.

Acceptance criteria

• It is established and recorded whether the Control API can be told to clear messageTtl, and by what representation
• If it can: removing message_ttl from a rule reverts the queue to its default TTL, verified against a real rule rather than only in the plan
• If it cannot: the ticket is closed against a Control API ticket that tracks the server-side change, and the provider documents the limitation rather than appearing to support it
• A subsequent plan is clean, with no perpetual diff on the attribute
• An acceptance test covers set-then-clear, extending the existing coverage in resource_ably_rule_amqp_external_test.go

Scope

• In scope: clearing message_ttl on ably_rule_amqp_external, in the provider and its vendored client
• Out of scope: other optional attributes with the same omitempty shape, unless the same fix covers them for free, and any wider change to how the provider serialises optional fields

Pointers

• control/types.go:411 - the vendored field and its omitempty
• internal/provider/rules.go:271 - where nil is produced on create and update
• internal/provider/rules.go:604 - the read path treating 0 as null
• internal/provider/resource_ably_rule_amqp_external_test.go:68 and :122 - existing TTL assertions
• GitHub issue 149, and SDK-2978

┆Issue is synchronized with this Jira Bug by Unito