[ISSUE #6967] Preserve discovery upstream props as divide upstream metadata.

[sunnysabor]

Fixes #6967

Problem

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 several built-in properties from props, such as warmup, gray, and healthCheckEnabled. The remaining custom properties are not preserved in the runtime upstream object.

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

Root Cause

The discovery-to-runtime conversion in the divide plugin parses DiscoveryUpstreamData.props only for built-in upstream options and then builds an Upstream without setting its metadata.

This means the existing discovery props extension channel works at the registry and admin data model level, but the data is dropped before the load balancer receives the runtime upstream list.

Solution

Parse discovery upstream props as a Map<String, String> and preserve it as Upstream.metadata during divide upstream conversion.

The same metadata map is also used to keep the existing parsing behavior for built-in properties:

• warmup
• gray
• healthCheckEnabled

Scope

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

For example, custom metadata should still be placed inside the props entry of the discovery instance metadata. This PR only makes those parsed props available from runtime Upstream.getMetadata().

Changed Behavior

• Existing parsing for warmup, gray, and healthCheckEnabled remains unchanged.
• Parsed discovery upstream props are copied into Upstream.metadata.
• Custom load balancers can read extension properties such as az, version, or grayTag from Upstream.getMetadata() when these properties are provided inside discovery upstream props.

Validation

• git diff --check
• mvn -pl :shenyu-plugin-divide -am -Dtest=DivideUpstreamDataHandlerTest -DfailIfNoTests=false test
• mvn -pl :shenyu-plugin-divide -am -DfailIfNoTests=false test
• ./mvnw clean install -Dmaven.javadoc.skip=true was not run locally.

Checklist

• You have read the contribution guidelines.
• You submit test cases (unit or integration tests) that back your changes.
• Your local test passed ./mvnw clean install -Dmaven.javadoc.skip=true.

[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 ab, x-version-tag, x-grey,
x-tag, 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.