[gin-dynamodb-valkey] demonstrate ctx propagation, SQS poller, outbound HTTP

[karthikeyangs9]

Summary

Refactor the gin-dynamodb-valkey example to demonstrate the patterns required for spans to link into one trace per request. Came out of debugging a customer (dev-quests-service) whose traces were producing single-span orphans even though agent.Start, ginagent.Middleware, and otelaws were all wired correctly — context.Context was not threaded through service / repository layers.

Changes

• Service struct holds clients only; methods take ctx context.Context as first arg. No struct-cached ctx — that's the most common cause of orphan span trees in real customer code.
• Custom internal spans via tracer.Start(ctx, "Service.X") so handler-side business logic appears as children of the gin SERVER span.
• Outbound HTTP via httpagent.NewClient + http.NewRequestWithContext — emits CLIENT spans nested under ctx and injects W3C traceparent for cross-service trace continuation. Bare http.Client orphans spans AND breaks downstream traces.
• SQS long-poll worker with trace.WithNewRoot() per iteration and a long-lived ctx (signal.NotifyContext on SIGINT/SIGTERM) so polls aren't cancelled mid-flight and recorded as STATUS_CODE_ERROR.
• Graceful shutdown via http.Server.Shutdown.
• README adds a Context Propagation note linking to the product integration doc.
• Removed stale go.mod.new.

Companion product-doc PR: last9/product-integrations#fix/golang-gin-ctx-propagation

Test plan

• gofmt -l . clean
• go vet ./... clean
• go build ./... clean
• docker compose up -d + create+seed table + go run . boots
• curl /users/u1 produces a trace with SERVER → Service.GetUser → DynamoDB.GetItem linked
• curl /external?url=https://httpbin.org/get produces SERVER → Service.CallExternal → HTTP GET linked, with traceparent header sent
• With SQS_QUEUE_URL set: poller emits sqs.poll root spans with process.message children; no STATUS_CODE_ERROR on empty queues