Change ordering of event drop mechanisms

As requested by @mitsuhiko this PR shall serve as basis for discussing the ordering of event drop mechanisms and its implications.

We are planning for `sample_rate` to update the session counts despite dropping an event (see getsentry/develop#551 and getsentry/develop#537). Without changing the order of filtering mechanisms this would mean any event dropped by `sample_rate` would update the session even if it would be dropped by `ignore_errors` which should not update the session counts when dropping an event. By changing the order we would first drop `ignored_errors` and only then check `sample_rate`, so session counts would not be affected in the case mentioned before. The same reasoning could probably be applied to `event_processor` and `before_send` but we don't know why a developer decided to drop an event there. Was it because they don't care about the event (then session should not be updated) or to save quota (session should be updated)? Also these may be more expensive in terms of performance (developers can provide their own implementations for both of those on some SDKs). So moving them before `sample_rate` would execute `before_send` and `event_processor` for every event instead of only doing it for the sampled events.

Author: adinauer

sentry_sdk/client.py

@@ -253,6 +253,9 @@ def _should_capture(
         if scope is not None and not scope._should_capture:
             return False
 
+        if self._is_ignored_error(event, hint):
+            return False
+
         if (
             self.options["sample_rate"] < 1.0
             and random.random() >= self.options["sample_rate"]
@@ -262,9 +265,6 @@ def _should_capture(
                 self.transport.record_lost_event("sample_rate", data_category="error")
             return False
 
-        if self._is_ignored_error(event, hint):
-            return False
-
         return True
 
     def _update_session_from_event(