feat(sfs): make resource pool wait timeouts configurable

[devpie]

Description

relates to #1737

stackit_sfs_resource_pool cannot create a pool that STACKIT needs more than 10 minutes to
provision. CreateResourcePoolWaitHandler and its update/delete counterparts set
SetTimeout(10 * time.Minute), and the resource passed a context without a deadline, so that
default was the only limit and no configuration could reach it.

This adds a timeouts attribute (create/read/update/delete) following the pattern of
dremio/instance.

Why a context deadline and not SetTimeout

core/wait.WaitWithContext applies the handler's own timeout only when the incoming context
carries no deadline:

if _, ok := ctx.Deadline(); !ok {
	ctx, cancel = context.WithTimeout(ctx, h.timeout)
	defer cancel()
}

(core v0.26.0, wait.go)

Setting a context deadline per CRUD method therefore replaces the hardcoded value, and no
SetTimeout call is needed. Defaults stay at the wait handler value plus
core.DefaultTimeoutMargin, so unconfigured resources keep their current behaviour.
TestSfsResourcePoolCreateTimeout checks that a configured timeouts.create bounds the create.

The wait error

When a wait ends because this context's deadline expired, the error names the configured timeout and
suggests raising it. The wait handler reports terminal error states and failing polls through the
same error, so the hint is added only on the deadline path, and identically in create, update and
delete. The hint is utils.TimeoutHint in stackit/internal/utils, so other resources can reuse it;
TestTimeoutHint pins its text.

On point 2 of the issue

The issue also asks to keep the resource in state when the wait times out. That is already
implemented: utils.SetAndLogStateFields writes the IDs before the wait (CONTRIBUTING.md states
this as project doctrine, and TestSfsResourcePoolSavesIDsOnError covers it), the framework
initialises the create response state to a null object so no unknowns leak, and Terraform keeps the
object and marks it tainted rather than discarding it. What follows is a replace, not a lost entry.
No provider change was needed for that, only the corrected wording of the error.

testdata/resource-pool-max.tf sets timeouts, and no ImportStateVerifyIgnore is needed for it: terraform-plugin-testing deletes timeouts and timeouts.* from
both sides of the comparison unconditionally, after the ignore loop
(testing_new_import_state.go:398-411, v1.16.0).
The DNS acceptance tests rely on the same behaviour.

Not changed

sfs/share has the same hardcoded 10 minutes in all three of its wait handlers. Out of scope for
this issue — happy to follow up if wanted.

Checklist

• Issue was linked above
• Code format was applied: make fmt
• Examples were added / adjusted (see examples/ directory) — deliberately not: no example in examples/ has ever carried a timeouts block (git log -S timeouts -- examples/ is empty), and feat(dns) add timeouts to dns resources and datasources #1345, which added timeouts to the DNS resources, put the demonstrable configuration in testdata/resource-max.tf instead. Hardcoding durations on a registry page would also pin numbers that go stale when the SDK waiter default moves.
• Docs are up-to-date: make generate-docs (will be checked by CI)
• Unit tests got implemented or updated
• Acceptance tests got implemented or updated — testdata/resource-pool-max.tf now sets timeouts, mirroring dns/testdata/resource-max.tf, so TestAccResourcePoolResourceMax covers the attribute across create, import-verify and update
• Unit tests are passing: make test (will be checked by CI)
• No linter issues: make lint (will be checked by CI)

[marceljk]

Thanks for your contribution! I left some minor comments

[devpie]

Follow-up in 7f8825e, after re-reading the result of the previous commit:

• the update wait branch still carried the summary Error creating resource pool while the appended hint named timeouts.update, so the diagnostic contradicted itself. Summary and detail now say "updating", matching what fix(sfs): guard against nil responses from the API #1741 changes the same line to, so the two should not conflict.
• the hint starts on its own line again; concatenating it onto the wrapped error ran the sentences together.
• the data source read timeout got the same blank line you asked for in the resource, and the acceptance-test data source now declares a timeouts block, as dns/testdata/resource-max.tf does for its data source.

I also removed a paragraph from the PR description that still described the state write you asked me to drop.

[marceljk]

Can you move this to our utils package, so it can be also reused by other resources and datasources in the future?

[devpie]

Moved in 06224ce. It now lives in stackit/internal/utils/timeouts.go as utils.TimeoutHint, since nothing in it is SFS-specific. TestTimeoutHint next to it pins the exact text for an exceeded deadline and checks that a cancellation, a wait that failed before the deadline and a context without a deadline produce no hint.