fix(outcomes): Do not report metrics-based outcomes for profiles

[jjbayer]

Profiles are no longer dropped by dynamic sampling, so we do not need to track the virtual "total profile" category with a tag on metrics.

This also prevents double-reporting (the rate limiter on the payload also emits an outcome for the profile category).

ref: getsentry/sentry#81799

[Dav1dde]

Nice!

Should double check if we can find any other mention of has_profile in (get)-sentry. I can't except in this test 👍 .

[Dav1dde]

Can use the same formatting as for spans here:

            MetricNamespace::Transactions => BucketSummary::Transactions(match self.value {
                MinimalValue::Counter(c) if mri.name == "usage" => c.to_f64() as usize,
                _ => 0,
            }),

[jjbayer]

Should double check if we can find any other mention of has_profile in (get)-sentry.

I found this constant, added in getsentry/sentry#64203.

@wmak is that list based on alert definitions that people actually use?

[jjbayer]

Decided we can merge this because the has_profile tag is only on c:transactions/usage@none, which is only used in the metrics billing consumer. I.e the tag cannot be accessed through the product.