feat(replays): add replay event to recording schema

[JoshFerge]

We're now sending the replay_event to the recording consumer on an optional key. Produced in getsentry/relay#3035, recording consumer change forthcoming

[github-actions]

versions in use:

The following repositories use one of the schemas you are editing. It is recommended to roll out schema changes in small PRs, meaning that if those used versions lag behind the latest, it is probably best to update those services before rolling out your change.

• getsentry/sentry: pip:sentry-kafka-schemas==0.1.38 (upgrade)
• getsentry/relay: rust:sentry-kafka-schemas==0.2.0 (upgrade)

latest version: 0.1.48

changes considered breaking

schemas/ingest-replay-recordings.v1.schema.json

• {"path": "", "change": {"PropertyAdd": {"lhs_additional_properties": true, "added": "replay_event"}}}
  

⚠️ This PR contains breaking changes. Normally you should avoid that and make
your consumer backwards-compatible (meaning that updated consumers can still
accept old messages). There are a few exceptions:

• If consumers already require these invariants in practice, and you're
  just adjusting the JSON schema to reality, ignore this warning.

• If you know what you are doing, this change could potentially be rolled out
  to producers first, but that's not a flow we support.

[JoshFerge]

i'm a a bit confused -- adding an optional field is considered a breaking change?

[lynnagara]

technically yes if additionalProperties = true, as any type would have been accepted before, and adding the property usually makes it stricter. In this case, since it's bytes and you haven't specified a type, the warning is wrong