fix: //orchestrion:ignore is not respected for Echo handlers

[Trighap52]

Why is this change being made?

//orchestrion:ignore was not effective for Echo routes because tracing was injected at router level (echo.New -> e.Use(echotrace.Middleware())), so ignored handlers were still traced.

This caused high-volume endpoints (for example readiness/liveness probes) to emit traces even when explicitly marked with //orchestrion:ignore.

What is the change?

• Added a built-in aspect that rewrites echo.New() to runtime/echoignore.New().
• Added runtime/echoignore helper package:
  • creates Echo router
  • installs echotrace.Middleware with WithIgnoreRequest(...)
  • skips tracing when matched route handler is registered as ignored
• Added injector pre-pass to register ignored Echo handlers by injecting:
  • var _ = echoignore.RegisterIgnoredEchoHandlerFunc(...)
• Added runtime tests for ignore handler registration and request-ignore matching.
• Added a samples regression case for ignored Echo handlers and updated snapshots.

How was this tested?

• go test ./runtime/echoignore
• go test ./internal/injector/...
• cd samples && go test -run TestSamples .

Fixes: #709

[RomainMuller]

Hey @Trighap52 the actual aspect that is used in live applications is in github.com/DataDog/dd-trace-go, what is in this repository is just an example for integrators.

[Trighap52]

Hi @RomainMuller Thanks, that makes sense. To make sure I move this in the right direction: should the fix live entirely in dd-trace-go’s Echo integration, or would you expect Orchestrion core to expose some generic mechanism for integrations to observe //orchestrion:ignore declarations?
My current understanding is that Echo-specific runtime behavior should move out of orchestrion, but I’m not sure whether the “register ignored handler” part should become a generic Orchestrion hook or be implemented fully inside the dd-trace-go aspect/runtime package.

[RomainMuller]

IMHO you'd want to do this fully in the dd-trace-go side… I don't think there would be a clean way to signal arbitrary registrations from "usage-agnostic" orchestrion to "usage-specific" tracer integrations. So in this case we'd probably want to introduce a dd-trace-go specific pragma/directive that would be used in this way…