Add log processing details and remove logsSampleRate (#13625)

- [feat: Remove logsSampleRate from logs develop
spec](881ae60):
Remove `logsSampleRate`. See
[https://linear.app/getsentry/issue/LOGS-95](https://linear.app/getsentry/issue/LOGS-95/tracking-discussion-on-logs-sampling)
for more context
- [feat: Specify details about integers and doubles in
attributes](99017ab):
Specify what integer and float values are allowed. This is useful for
SDKs like .NET, Native, and Rust
- [detail exact sdk behavior for log
processing](99b72bf):
Came up in slack, based on
#13614

Also update recommendation in buffer from 25 -> 100.

Author: AbhiPrasad

develop-docs/sdk/telemetry/logs.mdx

@@ -89,6 +89,8 @@ It consists of the following fields:
 
 : **Object, optional**. A dictionary of key-value pairs of arbitrary data attached to the log. Attributes must also declare the type of the value. The following types are supported: `string`, `boolean`, `integer`, `double`. In the future arrays will be supported (`string[]`, `boolean[]`, `integer[]`, `double[]`).
 
+Integers should be a 64-bit signed integer, while doubles should be a 64-bit floating point number. In the future we will support 64-bit unsigned integers.
+
 Example:
 
 ```json
@@ -156,27 +158,6 @@ The SDKs must expose the following configuration options:
 
 - `beforeSendLog`/`before_send_log`: A function that takes a log object and returns a log object. This function is called before sending the log to Sentry. It can be used to modify the log object or to prevent the log from being sent to Sentry. This function is optional.
 
-- `logsSampleRate`/`logs_sample_rate`: A number between 0 and 1 that represents the probability that a log will be sent to Sentry. This sampling decision should be made before a log is processed by SDK to lower performance overhead. Defaults to 1.0.
-
-```js
-Sentry.init({
-  enableLogs: true,
-
-  beforeSendLog(log) {
-    // Prevent logs from being sent to Sentry if the plan type is enterprise
-    if (log.attributes["plan.type"] === "enterprise") {
-      return null;
-    }
-
-    return log;
-  },
-
-  logsSampleRate: 1.0,
-});
-```
-
-At the current moment logs sampling decisions are not propagated to downstream services, or be affected by the `tracesSampleRate` configuration option. In the future there might be more advanced client-side sampling and server-side sampling strategies, but this is not yet defined.
-
 While the logs functionality for an SDK is in an experimental state, SDKs should put these configuration options in an experimental namespace to avoid breaking changes.
 
 ```js
@@ -279,15 +260,14 @@ It's important to note that putting everything immediately on a background threa
 
 The internal SDK implementation is kept purposefully broad as we are still in early stages. As we figure more out about the logs product and payload characteristics, we'll be able to define a more rigorous spec for logging internals in the SDK. SDKs should take care to not expose logging internals as much as possible to userland so that they can be refactored in the future.
 
-### Data Category and Rate Limiting
+In general log processing should follow this order:
 
-A new data category for logs has been added to Relay, `log_item`. Both the `log` envelope and `otel_log` envelope is covered by this data category. This will need to implemented in the SDK. Rate limiting applies as usual, there is no special rate limit or rate limiting behaviour for logs. With this data category, client outcomes should be tracked by the SDKs to track how often logs are dropped by the SDK.
-
-### Buffering
-
-Logs should be buffered before being sent. SDKs should keep a buffer of logs on the client (so you can have logs from multiple traces in the buffer) that flushes out based on some kind of condition. We recommend to use follow the [batch processor specification outlined](/sdk/telemetry/spans/batch-processor/) in the develop docs, but you should choose the approach that works best for your platform. When starting intial development on the SDK you can choose a simple approach to buffer like flushing logs if the buffer length exceeds 25 items, or if 5 seconds have passed.
-
-SDKS should NOT release logging capabilities to users if a buffering implementation has not been added to their SDK when adding logging APIs.
+1. Capture log via [Public APIs](#logger-module) (e.g. `Sentry.logger.info`) or via [SDK integrations](#sdk-integrations).
+1. Check if logging is enabled as per `enableLogs`/`enable_logs` configuration - if not, skip the rest of the steps.
+1. Process captured log (attach attributes as per [default attributes](#default-attributes)).
+1. Run `beforeSendLog`/`before_send_log` to filter or modify the log.
+1. Add log to buffer/batch processor as detailed in [buffering](#buffering).
+1. At time of flushing buffer, send array of logs to Sentry via `log` envelope, apply rate limiting as per [data category and rate limiting](#data-category-and-rate-limiting).
 
 ### Default Attributes
 
@@ -328,6 +308,16 @@ If a log is generated by an SDK integration, the SDK should also set the `sentry
 
 Beyond these attributes, we are exploring if the SDK should also send OS, user, and device information automatically (via reading the appropriate contexts from the scope). Given this behaviour can easily be added as a new feature to the SDK, it does not have to be part of the initial SDK implementation until we make a finalized decision.
 
+### Data Category and Rate Limiting
+
+A new data category for logs has been added to Relay, `log_item`. Both the `log` envelope and `otel_log` envelope is covered by this data category. This will need to implemented in the SDK. Rate limiting applies as usual, there is no special rate limit or rate limiting behaviour for logs. With this data category, client outcomes should be tracked by the SDKs to track how often logs are dropped by the SDK.
+
+### Buffering
+
+Logs should be buffered before being sent. SDKs should keep a buffer of logs on the client (so you can have logs from multiple traces in the buffer) that flushes out based on some kind of condition. We recommend to use follow the [batch processor specification outlined](/sdk/telemetry/spans/batch-processor/) in the develop docs, but you should choose the approach that works best for your platform. When starting intial development on the SDK you can choose a simple approach to buffer like flushing logs if the buffer length exceeds 100 items, or if 5 seconds have passed.
+
+SDKS should NOT release logging capabilities to users if a buffering implementation has not been added to their SDK when adding logging APIs.
+
 ### SDK Integrations
 
 SDKs should aim to have it so that console/logger integrations create logs as per the appropriate log level if `enableLogs`/`enable_logs` is set to true. Examples of this include JavaScript's `console` object and Pythons `logging` standard library.