Document Event.Exception.RawStacktrace about relay

[untitaker]

SDK developers are not supposed to set this attribute so I would not like to document this in SDK dev docs, but the code comments do need some love. We only have this:

relay/relay-general/src/protocol/exception.rs

Line 27 in 1f0d5f8

/// Optional unprocessed stack trace.

After server-side processing, the old SDK-provided stacktrace is backend up in this attribute

[jan-auer]

@untitaker We can take a pass through both sentry-docs (again 😄)and the protocol, to explicitly mark all fields as required, recommended or optional. Additionally, we can also qualify which attributes are for internal use only.

I'm thinking at least along the lines of how we documented outcomes (here it declares where an outcome is emitted):

relay/relay-server/src/actors/outcome.rs

Lines 80 to 82 in 1f0d5f8

	/// [Post Processing] An event with the same id has already been processed for this project.
	/// Sentry does not allow duplicate events and only stores the first one.
	Duplicate,

[rhcarvalho]

SDK developers are not supposed to set this attribute

I didn't know. For whatever reason, this field is defined and exported (public) in the Go SDK causing unnecessary confusion.

[untitaker]

Do you want to document culprit, title and Metadata as well? I considered them out of scope in principle, but in any case i see them in the same bucket as raw_stacktrace

[jan-auer]

The rule in the past was that we do not document internal attributes in external docs. Culprit, for example, was explicitly removed because it is no longer considered public API.

I would propose we mark all fields in Relay, and we ensure that this is also reflected in docs for all attributes that are not internal.

[RaduW]

I would propose to put all internal fields in an internal object, an internal object can appear at any level.
Anything under a field internal is ... internal and shouldn't be messed with by any SDK, similar to internal
packages in Go ( this should please Rodolfo).

[jan-auer]

Putting them in objects would be challenging, but we can have an annotation that is parsed and rendered in documentation, up to the point that we hide it in some places.

[RaduW]

Sure documenting it would help and would be easier that adding another sub-object any time you need some "private" fields. I still believe that serializing internal fields in an internal sub object would make it universally clear (whether you are looking at the structure definition, the structure usage, the serialized object or the documentation).