Java-Chassis2.8分支的ServicePathManager初始化流程的健壮性不足

## 问题原理分析

Java-Chassis做微服务调用的时候, 要求能从 `MicroserviceMeta` 中取出 `ServicePathManager` 实例. 而将 `ServicePathManager` 设置进 `MicroserviceMeta` 的逻辑是在 `RestEngineSchemaListener#onCreateMicroserviceVersion` 方法中执行的. 这个监听器从 guava `EventBus` 监听 `CreateMicroserviceVersionEvent` 事件, 并创建 `ServicePathManager` 与对应的 `MicroserviceVersion` 关联起来.

`RestEngineSchemaListener` 是在`BEFORE_REGISTRY`事件阶段注册到 `EventBus` 的, 也就是说, **如果有`MicroserviceVersion`对象是在`RestEngineSchemaListener`注册到 `EventBus` 之前创建的, 则它无法触发 `RestEngineSchemaListener` 执行上述动作, 也就不会有对应的 `ServicePathManager` 对象.** 而且, **这个问题是不可恢复的**, 一旦`MicroserviceVersion`对象有这个问题, 除非重启, 否则它一直会保持有问题的状态, 导致consumer端一直调用不了对应的producer微服务.

例如, EdgeService场景下, `EdgeInvocation#edgeInvoke` 就会触发创建`MicroserviceVersion`对象, 这是有可能在 `BEFORE_REGISTRY` 事件之前触发的(它不在`SCBEngine#ensureStatusUp`的保护范围之内).

## 建议

1. 能否取消`RestEngineSchemaListener`, 目前它做的事情就是在 `MicroserviceVersion` 对象创建出来的时候, 创建一个 `ServicePathManager` 对象与之对应. 这个流程能否挪到 `MicroserviceVersion` 自身的初始化方法中?
2. edge Dispatcher中也应该做 `SCBEngine#ensureStatusUp` 状态检查.

这两条都有价值做, 因为建议2无法完全拦截建议1涉及的场景.

まず RestEngineSchemaListener#onCreateMicroserviceVersion と MicroserviceVersion の初期化を追跡し、次に EdgeInvocation#edgeInvoke と SCBEngine#ensureStatusUp を調査します。EventBus への登録に先行し得る作成経路を確認します。すべての MicroserviceVersion が ServicePathManager を持ち、edge ディスパッチャーが必要なステータスチェックを処理すれば完了です。

索引モデルが issue の本文から書いたものです。