feat: add Definition list support (#11246)

* Revert "feat: Remove def list syntax (#11238)"

This reverts commit 2dba05e.

* add support for definition list

* Revert "fix: Remove unsupported definition list syntax (#10739)"

This reverts commit a715187.

* fix build errors

Author: a-hariti

develop-docs/backend/outboxes.mdx

@@ -5,7 +5,7 @@ title: Outboxes
 Outboxes are database backed deferred units of work that drive a large portion of our system's eventual consistency workflows. They were designed with a couple of key features in mind:
 
 - **Durability:** Outboxes are stored as database rows that are typically committed transactionally alongside associated model updates. They are retained until the processing code signals that work has been completed successfully.
-- **Retriability:** If an outbox processor fails for whatever reason, it will be reprocessed indefinitely until it succeeds. 
+- **Retriability:** If an outbox processor fails for whatever reason, it will be reprocessed indefinitely until it succeeds.
     - _Note:_ We do not support deadlettering, which means a head of line blocking outbox will continue to backlog work until the processing code is fixed.
 
 ## Outbox Properties
@@ -22,7 +22,8 @@ An outbox consists of the following parts:
 
 `object_identifier`
 
-: The ID of the impacted model object (if applicable). <br/><br/>*Note:* Not every outbox has an explicit model target, so this can be set to an arbitrary unique value if necessary. Just be aware that this identifier is used in tandem with the `shard_identifier` for coalescing purposes.
+: The ID of the impacted model object (if applicable).
+  *Note:* Not every outbox has an explicit model target, so this can be set to an arbitrary unique value if necessary. Just be aware that this identifier is used in tandem with the `shard_identifier` for coalescing purposes.
 
 `category`
 
@@ -107,9 +108,9 @@ Having both models aligned to the same database ensures that both the model chan
 
 ## Coalescing
 
-Outboxes are coalesced in order to prevent backpressure from toppling our systems after a blocked outbox shard is cleared. We accomplish this by assuming the last message in a coalescing group is the source of truth, ignoring any preceding messages in the group. 
+Outboxes are coalesced in order to prevent backpressure from toppling our systems after a blocked outbox shard is cleared. We accomplish this by assuming the last message in a coalescing group is the source of truth, ignoring any preceding messages in the group.
 
-An outbox’s coalescing group is determined by the combination of its sharding, `category` and `object_identifier` columns. 
+An outbox’s coalescing group is determined by the combination of its sharding, `category` and `object_identifier` columns.
 
 This coalescing strategy means that any outbox payloads that are stateful and order dependent in the same coalescing group *will* result in data loss when the group is processed. If you want to bypass coalescing entirely, you can set an arbitrary *unique* object identifier to ensure messages are run individually and in order; however, this can cause severe bottlenecks so be cautious when doing so.
 

develop-docs/sdk/client-reports.mdx

@@ -12,7 +12,7 @@ for events that were never sent.  Chained relays are also able to emit these
 client reports to inform the next relay in chain about _some_ outcomes.
 
 Due to a bug in Relay, which discards envelopes containing unknown envelope
-items, the minimum required version of Sentry for client reports is 
+items, the minimum required version of Sentry for client reports is
 [21.9.0](https://github.com/getsentry/relay/blob/master/CHANGELOG.md#2190).
 
 Before client reports were added there were no insights into the full number of events generated within applications instrumented with Sentry SDKs. It was always clear to track the number of events dropped on Sentry server side for any number of reason, but there was a gap in knowing just how many events were never sent from the SDKs at all. Are there patterns in different platforms? Are there problems we are not aware of? If a customer were to call Sentry and ask where there events are, we would have no answer, and no way to find out if there are truly missing events from their SDKs. Client reports removes some of this doubt. That being said we are not looking to perfectly measure every nuance and edge case of events being discarded in SDKs. It is more important to have a best effort and be able to gain insights to our SDKs and their host applications.
@@ -75,14 +75,11 @@ The following fields exist:
 
 `timestamp`
 
-_String | Number, optional_. The timestamp of when the client report was created.
-Must be an ISO DateTime string or a UNIX timestamp. If not sent, the server
-will assume the current UTC timestamp. In the data model, this is called
-`received`.
+: _String | Number, optional_. The timestamp of when the client report was created. Must be an ISO DateTime string or a UNIX timestamp. If not sent, the server will assume the current UTC timestamp. In the data model, this is called `received`.
 
 `discarded_events`
 
-_List of outcome objects_ (`reason`, `category`, `quantity`)
+: _List of outcome objects_ \{`reason`, `category`, `quantity`\}
 
 - `reason`: A string reason that defines why events were lost.
 - `category`: The data category for which the discard reason applies. These are the same data categories used for [rate limits](/sdk/rate-limiting/#definitions).
@@ -111,7 +108,7 @@ that SDKs send these under normal operation:
 
 `rate_limited_events`, `filtered_events`, `filtered_sampling_events`
 
-_List of outcome objects_ (`reason`, `category`, `quantity`)
+: _List of outcome objects_ \{`reason`, `category`, `quantity`\}
 
 These function like `discarded_events` but identify events that were rate limited,
 filtered or filtered by by dynamic sampling _at a relay_. Client SDKs must never

develop-docs/sdk/envelopes.mdx

@@ -119,19 +119,19 @@ Envelopes can have a number of headers which are valid in all situations:
 
 `dsn`
 
-**String, recommended.** An envelope can be self authenticated.  This means that
+: *String, recommended.* An envelope can be self authenticated.  This means that
   the envelope has all the information necessary to be sent to sentry.  In this
   case the full DSN must be stored in this key.
 
 `sdk`
 
-**Object, recommended.** This can carry the same payload as the <Link to="/sdk/event-payloads/sdk/">`sdk` interface</Link>
+: *Object, recommended.* This can carry the same payload as the [`sdk` interface](/sdk/event-payloads/sdk/)
   in the event payload but can be carried for all events. This means that SDK
   information can be carried for minidumps, session data and other submissions.
 
 `sent_at`
 
-**String, recommended.** The timestamp when the event was sent from the SDK as string in
+: *String, recommended.* The timestamp when the event was sent from the SDK as string in
   [RFC 3339](https://tools.ietf.org/html/rfc3339) format. Used for clock drift
   correction of the event timestamp. The time zone must be UTC.
 
@@ -153,22 +153,22 @@ The timestamp can be generated by any of the following (for example):
 
 JavaScript
 
-`new Date().toISOString()`
+: `new Date().toISOString()`
 
 Python
 
-`datetime.now(timezone.utc).isoformat()`<br />  
+: `datetime.now(timezone.utc).isoformat()`<br />
   *Don't use `datetime.utcnow()`, as it will omit the time zone.*
 
 .NET
 
-`DateTime.UtcNow.ToString("o", CultureInfo.InvariantCulture)`  
-  or  
+: `DateTime.UtcNow.ToString("o", CultureInfo.InvariantCulture)`
+  or
   `DateTimeOffset.UtcNow.ToString("o", CultureInfo.InvariantCulture)`
 
 Java
 
-`Instant.now().toString()`
+: `Instant.now().toString()`
 
 *Also note that the `sent_at` header replaces the `sentry_timestamp` key previously set in authorization headers,
 which has now been fully deprecated.  You should only send `sent_at`, and not `sentry_timestamp`.*
@@ -184,13 +184,13 @@ There are two generic headers for every Item:
 
 `type`
 
-**String, required.** Specifies the type of this Item and its contents. Based
+: **String, required.** Specifies the type of this Item and its contents. Based
   on the Item type, more headers may be required. See [Data Model](#data-model) for a list
   of all Item types.
 
 `length`
 
-**int, recommended.** The length of the payload in bytes. If no `length` is
+: *int, recommended.* The length of the payload in bytes. If no `length` is
   specified, the payload implicitly goes to the next newline. For payloads
   containing newline characters, the `length` must be specified.
 
@@ -323,7 +323,7 @@ encoded in JSON.
 
 `event_id`
 
-**UUID String, required.** Corresponds to the `event_id` field of the event
+: **UUID String, required.** Corresponds to the `event_id` field of the event
   payload. Clients are required to generate an event identifier ahead of time
   and set it at least in the Envelope headers. If the identifier mismatches
   between the Envelope and payload, the Envelope header takes precedence.
@@ -346,7 +346,7 @@ in JSON.
 
 `event_id`
 
-**UUID String, required.** Corresponds to the `event_id` field of the
+: **UUID String, required.** Corresponds to the `event_id` field of the
   transaction payload. Clients are required to generate an event identifier
   ahead of time and set it at least in the Envelope headers. If the identifier
   mismatches between the Envelope and payload, the Envelope header takes
@@ -380,17 +380,17 @@ file. It is always associated to an event or transaction.
 
 `event_id`
 
-**UUID String, required.** The identifier of the event or transaction.
+: **UUID String, required.** The identifier of the event or transaction.
 
 **Additional Item Headers:**
 
 `filename`
 
-**String, required.**  The name of the uploaded file without a path component.
+: **String, required.**  The name of the uploaded file without a path component.
 
 `attachment_type`
 
-**String, optional.** The special type of this attachment. Possible values are:
+: *String, optional.* The special type of this attachment. Possible values are:
 
   - **`event.attachment` (default)**: A standard attachment without special
     meaning.
@@ -402,11 +402,11 @@ file. It is always associated to an event or transaction.
     ingestion, event contexts and extra fields are extracted from this file.
   - `unreal.logs`: A plain-text log file obtained from UE4 crashes. During
     event ingestion, the last logs are extracted into event breadcrumbs.
-  - `event.view_hierarchy`: An JSON file with a predefined structure, see [RFC #33](https://github.com/getsentry/rfcs/blob/main/text/0033-view-hierarchy.md). 
+  - `event.view_hierarchy`: An JSON file with a predefined structure, see [RFC #33](https://github.com/getsentry/rfcs/blob/main/text/0033-view-hierarchy.md).
 
 `content_type`
 
-**String, optional.** The content type of the attachment payload. Any [MIME type](https://www.iana.org/assignments/media-types/media-types.xhtml) may be used; the default is `application/octet-stream`.
+: *String, optional.* The content type of the attachment payload. Any [MIME type](https://www.iana.org/assignments/media-types/media-types.xhtml) may be used; the default is `application/octet-stream`.
 
 ### Session
 
@@ -476,7 +476,7 @@ details.
 
 ### User Feedback
 
-User Feedback was called User Report in the beginning. Therefore the envelope item type is `"user_report"`. 
+User Feedback was called User Report in the beginning. Therefore the envelope item type is `"user_report"`.
 The item contains a user feedback / user report JSON payload:
 ```json
 {"event_id":"9ec79c33ec9942ab8353589fcb2e04dc","email":"[email protected]","name":"John Me","comments":"It broke."}\n
@@ -486,20 +486,20 @@ The item contains a user feedback / user report JSON payload:
 
 `event_id`
 
-**UUID String, required.** The identifier of the event or transaction.
+: **UUID String, required.** The identifier of the event or transaction.
 
 
 `email`
 
-**String, recommended.** The email of the user.
+: *String, recommended.* The email of the user.
 
 `name`
 
-**String, recommended.** The name of the user.
+: *String, recommended.* The name of the user.
 
 `comments`
 
-**String, recommended.** Comments of the user about what happened. 
+: *String, recommended.* Comments of the user about what happened.
 
 **Constraints:**
 
@@ -511,7 +511,7 @@ The item contains a user feedback / user report JSON payload:
 
 `event_id`
 
-**UUID String, required.** The identifier of the event or transaction.
+: **UUID String, required.** The identifier of the event or transaction.
 
 **Additional Item Headers:**
 
@@ -577,7 +577,7 @@ details.
 
 `length`
 
-**integer, required.** The size of the Replay recording payload
+: **integer, required.** The size of the Replay recording payload
 
 ### Profile
 
@@ -692,7 +692,7 @@ These limits are subject to future change and defined currently as:
 - *100MB* for each attachment item
 - *1MB* for event (errors and transactions), span, and metric (statsd, buckets, meta) items.
 - *100KB* for monitor check-in items
-- *50MB* for profile items 
+- *50MB* for profile items
 - *10MB* for compressed replay item
 - *100MB* for replay item after decompression
 - *100 sessions* per envelope