[BUG] Divide plugin does not preserve discovery upstream props as metadata

[sunnysabor]

Current Behavior

Discovery registry implementations such as Eureka and Nacos already read the props entry from instance metadata and store it in DiscoveryUpstreamData.props.

However, when the divide plugin converts DiscoveryUpstreamData to runtime Upstream, it only reads built-in properties such as warmup, gray, and healthCheckEnabled. Other custom properties are discarded.

As a result, custom load balancers cannot access discovery upstream extension properties from Upstream.getMetadata(), even though Upstream already provides a metadata field.

Expected Behavior

Parsed discovery upstream props should be preserved as runtime Upstream.metadata during divide upstream conversion.

This keeps the existing props extension channel and does not introduce full registry metadata passthrough.

Use Case

Custom load balancers should be able to read extension properties such as az, version, or grayTag from Upstream.getMetadata() when those properties are provided inside discovery upstream props.

Environment

• Apache ShenYu master branch
• divide plugin discovery upstream handling

[github-actions]

👋 Hello @yuluo-yx

A new issue has been opened by @sunnysabor:

• Title: [BUG] Divide plugin does not preserve discovery upstream props as metadata
• Link: [BUG] Divide plugin does not preserve discovery upstream props as metadata #6967

Please review when you have time. Thank you! 🙏

[sunnysabor]

Future Discussion

This PR intentionally keeps the scope small and only preserves the existing
discovery props extension channel as runtime Upstream.metadata.

There may be a broader question about whether ShenYu should support full
registry instance metadata passthrough in the future. In many production
environments, service-level information such as az, version, grayTag,
zone, or custom routing labels is usually stored directly in registry instance
metadata rather than being packed into a single props field.

Currently, registry implementations such as Eureka and Nacos only extract a
small set of known fields plus the props entry. This keeps the discovery model
stable, but it may also make custom routing and gray release scenarios harder to
integrate because users need to repack existing metadata into props.

It would be helpful to understand the community's view on this design:
whether ShenYu intends to keep props as the only generic extension channel, or
whether a full metadata passthrough model could be supported in a future change.

A full metadata passthrough would likely require a larger design discussion
because it may affect registry adapters, DiscoveryUpstreamData, admin storage,
sync data, and runtime upstream conversion. Therefore it is not included in this
PR.