feat: add noop client implementation

[giortzisg]

Description

This adds the Client interface and noop and default client implementations for the SDK. This better aligns the behavior with the current client spec and removes the need to always nil check any client.

Issues

• resolves: Finalize noop client prerequisite #1366
• resolves: GO-153

Changelog Entry Instructions

To add a custom changelog entry, uncomment the section above. Supports:

• Single entry: just write text
• Multiple entries: use bullet points
• Nested bullets: indent 4+ spaces

For more details: custom changelog entries

Reminders

• Add GH Issue ID & Linear ID
• PR title should use conventional commit style (feat:, fix:, ref:, meta:)
• For external contributors: CONTRIBUTING.md, Sentry SDK development docs, Discord community

[linear-code]

GO-153

[cursor]

Cursor Bugbot has reviewed your changes and found 2 potential issues.

There are 3 total unresolved issues (including 1 from previous review).

^{❌ Bugbot Autofix is OFF. To automatically fix reported issues with cloud agents, enable autofix in the Cursor dashboard.}

^{Reviewed by Cursor Bugbot for commit 8fc2ecf. Configure here.}

[cursor]

Disabled Recover skips panic recovery

Medium Severity

Recover returns immediately when the client is disabled, before calling recover(). Direct use as a panic handler with a noop client therefore leaves the original panic unrecovered. RecoverWithContext does not have this early return, so the two APIs now behave inconsistently for disabled clients.

Additional Locations (1)

• client.go#L766-L778

 

^{Reviewed by Cursor Bugbot for commit 8fc2ecf. Configure here.}

[sentry]

Bug: The logrus integration's check customHub.Client() != nil always passes now, as Client() returns a NoopClient instead of nil, causing logs to be silently discarded instead of falling back to the default hub.
_{Severity: HIGH}

Suggested Fix

Update the check in logrus/logrusentry.go:161 to use the IsEnabled() method instead of a != nil check on the client. The condition should be changed from customHub.Client() != nil to customHub.Client().IsEnabled(). This will correctly determine if the client is a real, functioning client or a NoopClient, restoring the intended fallback behavior.

Prompt for AI Agent

Review the code at the location below. A potential bug has been identified by an AI
agent. Verify if this is a real issue. If it is, propose a fix; if not, explain why it's
not valid.

Location: hub.go#L51-L54

Potential issue: The `hub.Client()` method was changed to always return a non-nil
client, specifically a `NoopClient` when no real client is configured. However, the
`logrus` integration at `logrus/logrusentry.go:161` was not updated. It still uses
`customHub.Client() != nil` to decide whether to use a custom hub. This check now always
evaluates to true. Consequently, if a custom hub lacks a real client, the system no
longer falls back to the default hub. Instead, it uses the custom hub with its
`NoopClient`, which silently discards all logs, leading to telemetry loss in certain
configurations like multi-tenant setups.

Also affects:

• logrus/logrusentry.go:161