[FEATURE] Migrate and Enhance Adaptive Service Throttling in dubbo-go 迁移并增强 dubbo-go 自适应限流能力

### 背景

dubbo-go 现在已经有一套自适应限流能力，主要包括：

- provider 侧的 `filter/adaptivesvc`
- consumer 侧的 `cluster/adaptivesvc`
- `p2c` load balance
- consumer 本地 metrics
- Hill Climbing 自适应并发控制算法

这套能力可以在 provider 侧根据实时请求情况动态调整并发上限，同时让 consumer 根据 provider 返回的剩余容量选择更合适的节点。

下一步我们希望对这块能力做一次系统梳理，并考虑把它迁移到 `dubbo-go-extensions`，让 dubbo-go 主仓库更加轻量。

### 要做的事情

1. **检查 dubbo-go 当前自适应限流能力**

需要先梳理当前已有能力，包括：

- provider 侧自适应限流 filter
- method 级别 limiter
- Hill Climbing 算法
- consumer 侧 adaptiveService cluster
- P2C 如何使用 provider 返回的 `remaining` 信息
- 当前配置入口和使用方式
- 已知限制和潜在问题

2. **做压力测试，看看能力上限**

需要补一组压测，验证当前实现的实际效果，比如：

- 高并发下是否能保护 provider
- RTT 升高时是否会自动缩容
- 服务恢复后是否会自动扩容
- 多 provider 场景下 P2C 是否能把流量打到更健康的节点
- reject 行为是否符合预期
- 当前硬编码参数是否存在瓶颈

压测结果需要形成简单报告，说明现有能力上限和发现的问题。

3. **把自适应限流插件迁移到 dubbo-go-extensions**

为了让 dubbo-go 主仓库更轻量，计划将自适应限流相关能力迁移到 `dubbo-go-extensions`。

迁移范围可以包括：

- `filter/adaptivesvc`
- `filter/adaptivesvc/limiter`
- `cluster/cluster/adaptivesvc`
- 相关 tests
- 必要文档

同时需要确认哪些基础能力应该继续留在主仓库，比如 `p2c`、`cluster/metrics`、相关 constants 等。

4. **给自适应限流补 dubbo-go-samples**

在 `dubbo-go-samples` 里增加一个可以直接运行的 sample，展示如何使用自适应限流。

sample 可以包括：

- server 开启 adaptive service
- client 使用 adaptiveService cluster 和 p2c
- 模拟慢请求 / 高并发 / reject 场景
- README 说明启动方式、配置方式和预期效果

5. **如果发现问题或瓶颈，可以继续升级**

如果压测或迁移过程中发现现有能力有明显问题，可以顺手进行升级，比如：

- limiter 参数配置化
- consumer metrics 增加 TTL
- 错误类型优化，避免依赖 error string
- 增加观测指标
- 支持更多 limiter 算法
- 优化多 consumer 场景下的行为

### 预期产出

- 当前自适应限流能力说明
- 压测结果和能力上限结论
- `dubbo-go-extensions` 中的 adaptive service 插件
- `dubbo-go-samples` 中的可运行示例
- 如有必要，提交能力增强 PR

---

## English Version

### Background

dubbo-go already has an adaptive service throttling mechanism, mainly including:

- provider-side `filter/adaptivesvc`
- consumer-side `cluster/adaptivesvc`
- `p2c` load balance
- local metrics on the consumer side
- Hill Climbing based adaptive concurrency control

This mechanism can dynamically adjust the concurrency limit on the provider side, and let the consumer choose a better provider based on the remaining capacity returned by each provider.

As the next step, we would like to review this feature, test its capability, and consider moving it to `dubbo-go-extensions` to keep the main dubbo-go repository lighter.

### Tasks

1. **Review the current adaptive throttling capability in dubbo-go**

We need to check what is currently supported, including:

- provider-side adaptive service filter
- method-level limiter
- Hill Climbing algorithm
- consumer-side adaptiveService cluster
- how P2C uses the `remaining` capacity returned by providers
- current configuration and usage
- known limitations and potential issues

2. **Run pressure tests to understand its capability limits**

We need to add pressure tests to verify how the current implementation behaves, for example:

- whether it can protect the provider under high concurrency
- whether it shrinks the concurrency limit when RTT increases
- whether it expands again after the provider recovers
- whether P2C sends more traffic to healthier providers
- whether reject behavior works as expected
- whether the current hardcoded parameters become bottlenecks

The result should be summarized in a simple report.

3. **Move the adaptive service plugin to dubbo-go-extensions**

To make the main dubbo-go repository lighter, we plan to move the adaptive service related implementation to `dubbo-go-extensions`.

Possible migration scope:

- `filter/adaptivesvc`
- `filter/adaptivesvc/limiter`
- `cluster/cluster/adaptivesvc`
- related tests
- required documentation

We also need to decide which shared components should stay in the main repo, such as `p2c`, `cluster/metrics`, constants, etc.

4. **Add dubbo-go-samples for adaptive service**

Add a runnable sample in `dubbo-go-samples` to show how to use adaptive service throttling.

The sample may include:

- server with adaptive service enabled
- client using adaptiveService cluster and p2c
- simulated slow requests / high concurrency / reject scenarios
- README with startup steps, configuration, and expected behavior

5. **Upgrade the feature if we find issues or bottlenecks**

If we find obvious problems during pressure testing or migration, we can improve the feature as part of this work, for example:

- make limiter parameters configurable
- add TTL for consumer-side metrics
- improve error types instead of relying on error strings
- add observability metrics
- support more limiter algorithms
- improve behavior in multi-consumer scenarios

### Expected Outputs

- A summary of the current adaptive service capability
- Pressure test results and capability limit analysis
- Adaptive service plugin in `dubbo-go-extensions`
- Runnable adaptive service sample in `dubbo-go-samples`
- Enhancement PRs if needed