fix(graceful_shutdown): use WithShutdown API in sample

[XiaoFeiASK]

变更说明

更新 graceful_shutdown sample，使其使用当前推荐的 dubbo.WithShutdown(...) 配置方式。

该 PR 主要解决 sample 仍使用旧的 graceful_shutdown.Init(...) 初始化方式的问题，并同步更新文档和集成测试说明。

问题原因

graceful_shutdown sample 原先通过 graceful_shutdown.Init(...) 配置优雅停机。

当前 Dubbo-go 推荐通过 dubbo.WithShutdown(...) 在 dubbo.NewInstance(...) 中配置 graceful shutdown。如果 sample 继续保留旧写法，用户容易参考到不推荐的 API，也会和当前文档中的新 API 使用方式不一致。

修复方案

• 将 graceful_shutdown.Init(...) 替换为 dubbo.WithShutdown(...)
• 使用 dubbo.NewInstance(...) 创建 Dubbo 实例
• 通过实例创建 Server，确保 graceful shutdown 配置从 Instance 传递到 Server
• 补充常用 graceful shutdown 配置项，包括 WithTimeout、WithStepTimeout、WithNotifyTimeout、WithConsumerUpdateWaitTime 和 WithOfflineRequestWindowTimeout
• 新增 -notify-timeout server 参数，并同步更新 README / README_CN
• 更新集成测试流程，使 graceful_shutdown sample 覆盖 Triple 长连接场景下的 graceful shutdown 行为

验证

• go test ./graceful_shutdown/...
• git diff --check

Fixes #1132

[Alanxtl]

我们的每一个sample同时也是集成测试
考虑一下怎么加一下集成测试 现在的graceful shutdown确实能够展示使用方法 但是还没有加入行为是否符合预期的判断

[XiaoFeiASK]

我们的每一个sample同时也是集成测试 考虑一下怎么加一下集成测试 现在的graceful shutdown确实能够展示使用方法 但是还没有加入行为是否符合预期的判断

Okay, I will try to add integration test

[Alanxtl]

集成测试的逻辑别加在 intergrate test里面 就加在代码里面 就用if或者select判断符不符合预期 不符合就panic就行了

[Alanxtl]

our project use import-formatter to format import blocks, that's the reason why ur CI fails. For you, u should

1. run go install github.com/dubbogo/tools/cmd/imports-formatter@latest
2. cd to the root dir of dubbo-go-samples
3. run imports-formatter

[XiaoFeiASK]

我们项目使用 import-formatter 来格式化导入块，这就是你的 CI 失败的原因。对你来说，你应该

1. 运行 go install github.com/dubbogo/tools/cmd/imports-formatter@latest
2. 切换到 dubbo-go-samples 的根目录
3. 运行 imports-formatter

ok，thanks for your review

[AlexStocks]

[P1] 这个本地标志会让集成测试绕过真正的优雅停机拒绝路径。triggerShutdownOnFirstGreet 在发送 SIGINT 前先把 shuttingDown 设为 true，第二个短连接请求即使穿过 Dubbo 的 provider graceful-shutdown filter，也会在这里由样例代码直接返回错误；客户端只统计 1 次成功和 1 次失败，所以框架的 RejectRequest 阶段失效时测试仍可通过。当前 CI 只显示该 sample 退出成功，client/server 日志被重定向，无法区分错误来源。请去掉应用层拒绝，改为在框架进入拒绝阶段后由独立客户端发起请求，并断言请求没有进入 Greet handler，同时保留在途请求完成的断言。

[XiaoFeiASK]

done

[AlexStocks]

[P1] 当前修复仍未覆盖停机阶段的拒绝切换。第二阶段通过 -reject-request=true 在 server 启动前直接执行 WithRejectRequest()，随后没有发送 SIGINT；第一阶段又只有一个在途请求，没有停机后的新请求。因此即使删除 Dubbo-Go waitForSendingAndReceivingRequests() 中真正把 RejectRequest 从 false 置为 true 的逻辑，这个测试仍会通过。请在同一次真实停机中，等待 SIGINT 后框架进入拒绝阶段，再由独立客户端发起新请求并断言未进入 Greet handler；回归测试必须能检出移除该状态切换的实现。

[AlexStocks]

[P1] 当前 Head ed5613e 仍可复现这个根因。我在 WSL / Go 1.25.1 的隔离副本中删除了 Dubbo-Go 387ea9a 的 waitForSendingAndReceivingRequests 内唯一一处 shutdown.RejectRequest.Store(true)，再运行 bash ./integrate_test.sh graceful_shutdown，脚本仍以 0 退出，并完整打印 Triggering graceful_shutdown、reject-stage probe 和 integration completed。原因是第二阶段通过 -reject-request=true 在新进程启动时预置拒绝状态，而第一阶段收到 SIGINT 后没有发起新请求，所以测试无法检出真实停机状态切换缺失。请在同一服务进程收到 SIGINT 后发起独立新请求，断言它未进入 Greet handler，并移除用 WithRejectRequest 预置结果的第二阶段。

[XiaoFeiASK]

I have fixed CI😀

[XiaoFeiASK]

新增修改：

• graceful_shutdown/go-server/cmd/main.go
  问题：为测试构造内部 ShutdownConfig，使用 NewOptions / SetShutdownConfig / server.SetServerShutdown，偏离 sample 应展示的公开 API 用法。
  修复：恢复为直接 dubbo.WithShutdown(...) 传入 graceful shutdown options，并使用 ins.NewServer() 创建 server。
  影响：sample 继续展示推荐的实例级公开配置方式，避免用户参考内部配置注入写法。
• integrate_test.sh
  问题：自然 graceful shutdown 的 reject 窗口过短，独立 probe 可能在 listener 关闭后才发起，只得到 connection refused，无法证明请求被 provider graceful-shutdown filter 拒绝。
  修复：将 graceful_shutdown 集成测试拆分为两段：第一段验证 in-flight 请求在 shutdown 后完成；第二段启动带 -reject-request=true 的 server，使用独立短连接 probe 稳定验证框架拒绝路径。
  影响：同时满足 in-flight drain 与 framework reject path 的行为验证，避免 CI 依赖短暂时序窗口产生 flake。