Add other algorithms to the rate limit processor

[romain-chanu]

Describe the enhancement:

1. As per Rate limit processor #22883, the rate limit processor uses the token bucket algorithm.

Given the token bucket algorithm implementation, we expect the rate limit processor to conform to the configured rate over a long enough period of time, but not for every single time period, e.g. 12 events per hour every hour.

2. There are use cases that require users to have an exact number of events per time period. Being able to configure the rate limit processor with a different algorithm (e.g sliding log rate limit algorithm) could be the solution, at the expense of a higher memory usage.

Describe a specific use case for the enhancement or feature: Add other algorithms (e.g sliding log rate limit algorithm) to the rate limit processor

[botelastic]

This issue doesn't have a Team:<team> label.

[StephanErb]

And ideally the rate limiter should create a field that can be reacted on in downstream processors instead of dropping the message outright. This enables additional opportunities such as dropping stack traces but keeping the message.

[ycombinator]

And ideally the rate limiter should create a field that can be reacted on in downstream processors instead of dropping the message outright. This enables additional opportunities such as dropping stack traces but keeping the message.

@StephanErb Would you mind making a separate issue for this enhancement?