feat(grouping): Add hashing_metadata field to GroupHashMetadata table

[lobsterkatie]

This adds a new field, hashing_metadata, to the GroupHashMetadata table, to serve as a compliment to the hash_basis field added in #79835.

Whereas that field stores the overall grouping method (stacktrace, message, custom fingerprint, etc.), this new field will store more detailed, grouping-method specific data. For example, when grouping on message, it will store whether or not the message was parameterized; when grouping on fingerprint, it will store the source of the fingerprint; when grouping on stacktrace, it will note whether the stacktrace was found in an exception or in a thread. (The full scope of the data stored for each grouping method can be found in the XYZHashingMetadata types added in this PR.)

Code to add data to this field is included in #80534.

[codecov]

Codecov Report

All modified and coverable lines are covered by tests ✅

✅ All tests successful. No failed tests found.

Additional details and impacted files

@@            Coverage Diff             @@
##           master   #80531      +/-   ##
==========================================
- Coverage   78.41%   78.41%   -0.01%     
==========================================
  Files        7209     7210       +1     
  Lines      319651   319691      +40     
  Branches    44003    44003              
==========================================
+ Hits       250669   250700      +31     
- Misses      62596    62605       +9     
  Partials     6386     6386              

[lobsterkatie]

if we use GZipDictField, these parameters won't be queryable in redash/bigquery, which means that overall our idea to use postgres as a datastore won't work.

Right! That's why I originally had it as a JSON field. I couldn't remember why I'd chosen that over the gzipdict, and so I swapped it in order to get the defaults-to-an-empty-dict-rather-than-null behavior. But past-past-me was smarter than recent-past me - you're absolutely right, it should be JSON.

Thank you for catching that!

[github-actions]

This PR has a migration; here is the generated SQL for src/sentry/migrations/0791_add_hashing_metadata_to_grouphash_metadata.py ()

--
-- Add field hashing_metadata to grouphashmetadata
--
ALTER TABLE "sentry_grouphashmetadata" ADD COLUMN "hashing_metadata" text NULL;

[JoshFerge]

why does this need to be repeated HashingMetadata | None, HashingMetadata | None?

[lobsterkatie]

Not well documented (that I could find), but this is the setter type and the getter type: https://github.com/typeddjango/django-stubs/blob/ab4dcfa002dbe138b7548086328f13cbde3c41b3/django-stubs/db/models/fields/__init__.pyi#L46-L51.