add explanation fore eager scaling strategy (kedacore#1438)

Signed-off-by: Zbynek Roubalik <zroubalik@gmail.com>
Signed-off-by: shubhusion <shubham27.sharma03@gmail.com>

Author: zroubalik

content/docs/2.15/reference/scaledjob-spec.md

@@ -150,7 +150,7 @@ scalingStrategy:
   strategy: "default"                 # Optional. Default: default. Which Scaling Strategy to use. 
 ```
 
-Select a Scaling Strategy. Possible values are `default`, `custom`, or `accurate`. The default value is `default`.
+Select a Scaling Strategy. Possible values are `default`, `custom`, `accurate`, or `eager`. The default value is `default`.
 
 > 💡 **NOTE:**
 >
@@ -221,6 +221,59 @@ if (maxScale + runningJobCount) > maxReplicaCount {
 ```
 For more details,  you can refer to [this PR](https://github.com/kedacore/keda/pull/1227).
 
+**eager**
+When adopting the **default** strategy, you are likely to come into a subtle case where messages need to be consumed by spawning jobs but remain in the queue, even when there are available slots between `runningJobCount` and `maxReplicaCount`. The **eager** strategy comes to the rescue. It addresses this issue by utilizing all available slots up to the maxReplicaCount, ensuring that waiting messages are processed as quickly as possible.
+
+For example, let's assume we configure a ScaledJob in a cluster as below:
+```yaml
+  ###
+  # A job that runs for a minimum of 3 hours.
+  ###
+  pollingInterval: 10 # Optional. Default: 30 seconds
+  maxReplicaCount: 10 # Optional. Default: 100
+  triggers:
+    - type: rabbitmq
+      metadata:
+        queueName: woker_queue
+        hostFromEnv: RABBITMQ_URL
+        mode: QueueLength
+        value: "1"
+```
+We send 3 messages to the Rabbitmq and wait longer enough than the `pollingInterval`, then send another 3.
+
+With the `default` scaling strategy, we are supposed to see the metrics changes in the following table:
+
+|             | initial | incoming 3 messages | after poll | incoming 3 messages | after poll |
+|-------------|---------|---------------------|------------|---------------------|------------|
+| queueLength | 0       | 3                   | 3          | 6                   | 6          |
+| runningJobs | 0       | 0                   | 3          | 3                   | 3          |
+
+
+If we switch to `eager`, the result becomes: 
+
+|             | initial | incoming 3 messages | after poll | incoming 3 messages | after poll |
+|-------------|---------|---------------------|------------|---------------------|------------|
+| queueLength | 0       | 3                   | 3          | 6                   | 6          |
+| runningJobs | 0       | 0                   | 3          | 3                   | 6          |
+
+We can identify the difference in their final states.
+
+
+You may also refer to [this original issue](https://github.com/kedacore/keda/issues/5114) for more information.
+
+---
+
+```yaml
+scalingStrategy:
+    multipleScalersCalculation : "max" # Optional. Default: max. Specifies how to calculate the target metrics (`queueLength` and `maxScale`) when multiple scalers are defined.
+```
+Select a behavior if you have multiple triggers. Possible values are `max`, `min`, `avg`, or `sum`. The default value is `max`. 
+
+* **max:** - Use metrics from the scaler that has the max number of `queueLength`. (default)
+* **min:** - Use metrics from the scaler that has the min number of `queueLength`.
+* **avg:** - Sum up all the active scalers metrics and divide by the number of active scalers.
+* **sum:** - Sum up all the active scalers metrics.
+
 
 ### multipleScalersCalculation