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涉及的场景.