fix:fix incorrect empty metadata data handling.

[SkyeBeFreeman]

fix #75

实例更新流程

核心逻辑源码：org.apache.dubbo.registry.client.event.listener.ServiceInstancesChangedListener#doOnEvent

1. 当dubbo订阅（subscribe）URL的时候，会绑定实例变更监听器（ServiceInstancesChangedListener）。

2. 在polaris-dubbo-java中，将绑定polaris-java定义的变更监听器（InnerServiceListener）与之对应。

3. 实例更新时，会触发实例变更监听器的doOnEvent方法。

4. 实例变更监听器从新的实例列表，解析出revision映射到实例列表的map。

5. 针对每个revision，先从实例中获取service metadata，如果没有，再去远端拉取service metadata。

6. 将获取的service metadata塞回实例内。

7. 最后构造url，并刷新

原有逻辑

在上述流程的第5步，获取到service metadata拉取到空值，也会正常更新。例如下方serviceInfos为空map，也正常返回了。

解决方案

1. 可以借助dubbo的metadata异常处理流程来完成service metadata的拉取。也就是serviceInfos为空map时，返回dubbo框架内指定的空值，MetadataInfo.EMPTY。

2. dubbo框架在获取远端service metadata时，如果拿到了MetadataInfo.EMPTY，则会重试2次，且每次重试间隔1000ms。源码：org.apache.dubbo.registry.client.AbstractServiceDiscovery#getRemoteMetadata(java.lang.String, java.util.List<org.apache.dubbo.registry.client.ServiceInstance>)

3. 如果重试后还是为MetadataInfo.EMPTY，则会走到实例变更监听器重试逻辑。这个重试逻辑会判断是否有实例存在空的service metadata，则会提交一个重试任务，等待10000ms后，重新触发整个url列表的变更。

4. 经过两层重试后，便可正确获取service metadata，即使是北极星AP架构。

[andrewshan]

LGTM