feat: Magic to take and honor a context

[ayashjorden]

Check Existing Issues

• I have searched the existing issues and discussions.

Problem Description

As this library is consumed by other projects, it is desirable to enable passing in a context object, thus supporting cancel-s, timeouts, and more.
This issue may be further broken down to the different functionality-areas (Storage being just one), avoid huge PRs and dependencies.

Desired Solution you'd like

Update StorageAdapter interface's methods to take a context as first argument (golang standard), and pass it internally to DB client libraries.

Determine what other areas in the codebase need to support passing in a context.

Additional Context

No response

[Lutherwaves]

Concrete context.TODO() inventory from a recent audit, to make this actionable. These are the call sites that should accept and honor a caller-provided context.Context:

leadership/leadership.go

• :118 a.DB.CreateTable(context.TODO(), input)
• :124 waiter.Wait(context.TODO(), &dynamodb.DescribeTableInput{...})
• :142 table-creation wait path
• :305 a.DB.GetItem(context.TODO(), ...)
• :342 a.DB.ExecuteStatement(context.TODO(), ...)

pubsub/sns.go

• :23 awsconfig.LoadDefaultConfig(context.TODO()) (init path — context.Background() is acceptable here, but a ctx param would let callers bound init)

storage/dynamodb.go

• :44 config.LoadDefaultConfig(context.TODO()) (same init-path note)

Prior art / related work

• O11y #170 (O11y, merged) added global and context-scoped telemetry resolution, so the telemetry layer already threads context.
• feat(storage): add WithContext for ctx threading in SQL and Memory adapters #164 (closed) — feat(storage): add WithContext for ctx threading in SQL and Memory adapters — is directly relevant prior art. It chose the additive WithContext(ctx) wrapper (mirroring database/sql's *Context pattern) and explicitly avoided changing every CRUD method signature on the StorageAdapter interface, calling that an interface-breaking change. The current code reflects this: SQL/Memory expose *Context method variants, while the non-context methods delegate with context.Background().

Open scope decision

Given the above, the storage half is largely addressed; the biggest remaining gap is leadership, which has no context plumbing at all. Worth pinning down the intended shape before splitting this issue:

• A) Keep the additive *Context / WithContext approach (non-breaking) and just fill the leadership (and init-path) gaps.
• B) Make context first-class on the StorageAdapter interface by changing method signatures (breaking API change), as the original description suggests.

Once the direction is settled, the natural breakdown is small (~storage-signature / leadership / init-paths), not a large fan-out.

[Lutherwaves]

@ayashjorden @deanefrati worth a discussion here