feat(sdk-crashes): Set project id as user id

[philipphofmann]

Set the project id as the user id, so Sentry can tell how many projects are impacted by an SDK crash.

[codecov]

Codecov Report

Merging #52331 (24063cc) into master (a54d212) will decrease coverage by 0.01%.
The diff coverage is 100.00%.

Additional details and impacted files

@@            Coverage Diff             @@
##           master   #52331      +/-   ##
==========================================
- Coverage   79.31%   79.31%   -0.01%     
==========================================
  Files        4908     4908              
  Lines      205703   205704       +1     
  Branches    35164    35164              
==========================================
  Hits       163160   163160              
  Misses      37556    37556              
- Partials     4987     4988       +1     

Impacted Files	Coverage Δ
...rc/sentry/utils/sdk_crashes/sdk_crash_detection.py	95.00% <100.00%> (+0.12%)	⬆️

... and 3 files with indirect coverage changes

[jjbayer]

If we're only interested in the number of users (not tracking those users down), should we hash the project id here, to be on the safe side of any privacy concerns?

[philipphofmann]

We already store the project id here

sentry/src/sentry/utils/sdk_crashes/sdk_crash_detection.py

Lines 62 to 65 in a54d212

	value={
	"original_project_id": event.project.id,
	"original_event_id": event.event_id,
	},

There is nothing you can do with the project id. Only with admin rights in Sentry you can find and access the project. Why do you think there are any privacy concerns?

[jjbayer]

OK, missed that. I may have been thinking too far ahead -- if this ever becomes a more general "sentry for library developers" feature and we make these errors public, we have to make sure that this user ID cannot be traced back to the original organization. As long as this is our own private feature, this should be fine though.

[philipphofmann]

Excellent that you think ahead, but this is not a problem right now.

[jjbayer]

OK, missed that. I may have been thinking too far ahead -- if this ever becomes a more general "sentry for library developers" feature and we make these errors public, we have to make sure that this user ID cannot be traced back to the original organization. As long as this is our own private feature, this should be fine though.