Fix KPA bug, and an elaborate KPA test case

[kr11]

Pull Request Description

[Please provide a clear and concise description of your changes here]

Related Issues

Resolves: #407

Important: Before submitting, please complete the description above and review the checklist below.

This PR is marked as WIP, pending the merge of #511.

Bug Fixes and Enhancements to KPA

1. KPAScaler now initializes using the current replica count of pods.
2. KPAScaler now starts in panic mode, aligning with the KNative implementation.
3. Enable users to specify panicWindow in pa.yaml.

Add an Elaborate Test Case

A detailed test case for KPA behavior (kpa_test.go TestKpaScale2) has been added, covering the following scenario:

1. KPA starts in panic mode.
2. Metrics remain low, and no downscaling occurs due to the initial panic mode.
3. After persistent low metrics, KPA exits panic mode; however, downscaling is delayed due to the DelayWindow.
4. Once the maximum DelayWindow duration decreases to a lower level, downscaling occurs.
5. As metrics begin to rise, the PanicWindow suggests scaling up to 3 replicas, but this does not surpass the panic threshold. The StableWindow advises maintaining 2 replicas. Ultimately, KPA stabilizes at two replicas without re-entering panic mode.
6. With continuing metric increases, the StableWindow suggests scaling up to 3 replicas, remaining below the panic threshold, thus no new panic mode is triggered, but scaling up occurs.
7. Metrics increase further, surpassing the scaling rate threshold, triggering a re-entry into panic mode.
8. As metrics keep rising, the panic time is updated.
9. Upon metrics stabilization, KPA remains in panic mode but stops updating the panicTime.

---

Contribution Guidelines (Expand for Details)

We appreciate your contribution to aibrix! To ensure a smooth review process and maintain high code quality, please adhere to the following guidelines:

Pull Request Title Format

Your PR title should start with one of these prefixes to indicate the nature of the change:

• [Bug]: Corrections to existing functionality
• [CI]: Changes to build process or CI pipeline
• [Docs]: Updates or additions to documentation
• [API]: Modifications to aibrix's API or interface
• [CLI]: Changes or additions to the Command Line Interface
• [Misc]: For changes not covered above (use sparingly)

Note: For changes spanning multiple categories, use multiple prefixes in order of importance.

Submission Checklist

• PR title includes appropriate prefix(es)
• Changes are clearly explained in the PR description
• New and existing tests pass successfully
• Code adheres to project style and best practices
• Documentation updated to reflect changes (if applicable)
• Thorough testing completed, no regressions introduced

By submitting this PR, you confirm that you've read these guidelines and your changes align with the project's contribution standards.