ai-proxy 插件后续开发任务

[cr7258]

任务	PR	进度
从 ai-proxy 插件中抽离 provider 逻辑，以便其他插件进行复用		⏳未开始
支持请求失败时，对本次请求立即进行重试		⏳未开始
增加 ai-proxy 插件的 E2E 测试		⏳未开始
支持按照 model 维度进行 failover， 例如 qwen-max 限流比较严重，fallback 退化到 qwen-plus 仍然可以使用		⏳未开始
当所有 apiToken 都被拉黑之后，将所有 apiToken 从黑名单中放出 避免 ai-proxy 插件自身逻辑有问题误将 apiToken 移除的情况		⏳未开始

[johnlanni]

@cr7258 补充两个点：

1. api key failover 的粒度目前是 provider ，可以支持一下 model
2. 当所有 api key 都被拉黑之后，不应该返回 api key 都不可用，变成 higress 自身产生的错误，建议是没有可用 api key 时，将所有 api key 都从黑名单中放出

[cr7258]

当所有 api key 都被拉黑之后，不应该返回 api key 都不可用，变成 higress 自身产生的错误，建议是没有可用 api key 时，将所有 api key 都从黑名单中放出

我反而觉得在所有 apikey 不可用时，让 higress 直接返回错误信息是不是会更好？ 让用户知道 api key 有问题，应该进行人工干预。

将所有 api key 都从黑名单中放出既不能改变请求失败的结果（因为一旦有 api key 健康检测通过就会被加回来，全放出来还是全部都失败），另外这么做可能也会让逻辑更复杂些。

[johnlanni]

@cr7258 主要我担心所有 apikey 都被拉黑的情况，可能是我们自身逻辑或者突发网络问题等。所以如果从健壮性上考虑，都被拉黑时一次性都放出来会更合理一些

[cr7258]

@johnlanni Ok