feat(bk-cache/jwt-key.lua): ha refactor to make the dp robust

[wklken]

Description

目标：即使依赖的第三方服务挂了，也能持续运行一段时间，确保大部分访问过的请求还能继续访问，直到服务恢复

• 鉴于 jwt 不会改变（且查询不到 404 不会缓存）， 将 lrucache的 ttl 改成 24 小时（如果改变，需要reload）

Checklist

• 填写 PR 描述及相关 issue (write PR description and related issue)
• 代码风格检查通过 (code style check passed)
• PR 中包含单元测试 (include unit test)
• 单元测试通过 (unit test passed)
• 本地开发联调环境验证通过 (local development environment verification passed)

[wklken]

公共：

• 【规范的】jwt-key 增加当前 lrucache ttl 即可, 24 小时
  • gateway_name => public_key
  • 所有失败的都不会被缓存；
• 【特殊的】app-account, 依赖 bkauth, ttl=600s;
  • 缓存的是 app_code+app_secret => {existed=, verified=}；即，不存在也会被缓存/存在被缓存；
  • 应用不存在 {existed=false, verified=false}
  • 应用存在，但是 verified 取决于是否命中 {existed=true, verified=true/false}

ee 版本：

• 【规范的】access_token， 依赖 SSM, ttl=600s
  • 网络错误/非 200/非json 等，不会被缓存
  • body.code !=0， 也不会被缓存
  • 只缓存正确的
• 【规范的】bk_token, 依赖 login, ttl=600s; 且 bk_token 有效期是 1 天 【特殊的】
  • 网络错误/非 200/非json 等，不会被缓存
  • 返回 200， body.bk_error_code != 0 会被缓存错误信息{error_message:}; 否则缓存{username:}

te 版本：

• 【规范的】access_token， 依赖 authapi, ttl=600s
  • 网络错误/非 200/非 json 等，不会被缓存
  • body.code = 0 不会被缓存
  • 正确的才会被缓存
• 【特殊的】bk_ticket， 依赖 login, ttl 600s;
  • 网络错误/非 200/非 json 等，不会被缓存
  • 返回 200， body.code in [0,2003]错误， 以及正确，都会被缓存；

[wklken]

整体方案：

1. 在现有的 lrucache 基础上提升可用性，但是目前的 lrucache 库不支持设置每个key 的时间长短
2. 多加一层cache， 另一个lrucache 或者shared_dict， 将正确的值放进去，并在第三方服务挂了的时候，直接从这一层cache取；

• 但是，需要放到那一层？ bk-component层能识别服务是否挂，bk-cache层无法识别； 但是bk-cache层拿到的已经是封装后的数据（无法判定是不是异常，还是业务错误？）

[wklken]

问题：

• lrucache 只有 get命中才记数，此时如果只有在connection refused才有get，那么意味着这个 lrucache 是按顺序放进去，满了之后，按进入的顺序被清理 =》 此时如果有个调用方一直再使用刷新的access_token（每次发请求都刷新一个），那么意味着我们的缓存在这种场景下将没什么效果

-》 应该调用一次get? 相当于命中加权，避免自己被清理

---

set 也会更新 lru 计数，所以理论上没问题，除非刷的这个流量大于始终使用固定值的流量

https://github.com/openresty/lua-resty-lrucache/blob/master/lib/resty/lrucache.lua#L262C18-L262C22

[wklken]

相对于原先的逻辑，每一个请求会多 1-2 次 cache set 的操作

[Han-Ya-Jun]

LGTM