feat(tp): add rate limiting checks

[solnic]

This addresses suggestions from #987 (review) specifically:

You could already drop rate-limited items before adding them to the buffer. And you could drop rate-limited items in the scheduler before you pass them down to the transport

---

#skip-changelog

[github-actions]

	Messages
📖	Do not forget to update Sentry-docs with your feature once the pull request gets approved.

Generated by 🚫 dangerJS against 6c14e1c

[cursor]

Cursor Bugbot has reviewed your changes and found 1 potential issue.

^{Bugbot Autofix is OFF. To automatically fix reported issues with Cloud Agents, enable Autofix in the Cursor dashboard.}

[philipphofmann]

Oops, I'm sorry. I think this might not have been 100% clear.

Before adding an item to a specific buffer, the telemetry buffer SHOULD drop rate-limited items to avoid overhead. If doing so, it MUST record client reports.
Telemetry Processor

If a rate limit is active, we recommend SDKs to all the rate limited data, see

Events, transactions, sessions, and/or any other supported payload type, depending on the communicated limits, are to be discarded during the period that the rate limit is in place.
Rate Limiting

Do you think I should change the develop docs accordingly so this is clearer, or do you think it is clear enough?

I could add an extra sentence that clearly specifies: when the buffer applies rate limits, it must drop them and not wait to send. I could also update the develop docs on rate limiting to more clearly point this out. Would that help?

[solnic]

@philipphofmann thanks for clarification! should we be sending client reports or just completely ignore dropped items as if nothing ever happened? 🙃