[AppConfig-BugFix] Preserve unknown properties in FeatureFlag and SecretReference ConfigurationSettings

[mssfang]

FeatureFlagConfigurationSetting and SecretReferenceConfigurationSetting will now retain custom attributes in the setting value. Previously, only attributes that were defined in the associated JSON schema were allowed and unknown attributes were discarded.

fixes: #34904

• FeatureFlagConfigurationSetting can take unknown properties other than the swagger-defined property definition. Such as

featureFlag.setValue("{\"conditions\":{\"requirement_type\":\"All\"}}"); // "requirement_type" is user-defined property

Users can edit the ConfigurationSetting's value directly or through Azure Portal UI.

• Also, added similar consideration to SecretReferenceConfigurationSetting.

[azure-sdk]

API change check

APIView has identified API level changes in this PR and created following API reviews.

azure-data-appconfiguration

[alzimmermsft]

Just trying to understand this change a bit more before giving a detailed review. What we're trying to support is FeatureFlagFilters that don't conform to the standard {"name":"name","parameters":{...}}? Or is this additional data additional JSON properties in the Feature Flag Configuration setting, {<regular Feature Flag JSON>,"additionalProperty":"additionalValue"}?

[mrm9084]

Just trying to understand this change a bit more before giving a detailed review. What we're trying to support is FeatureFlagFilters that don't conform to the standard {"name":"name","parameters":{...}}?

The service supports any custom values that the customer wants, or any additional fields the service team wants.

For example we are trying to add a requirement_type field that allows for switching between or/and logic for feature flags. Currently if any modifications are made to the feature flag object any unknown fields are erased which shouldn't happen.

This issue is present in most of the SDKs.

[alzimmermsft]

Just trying to understand this change a bit more before giving a detailed review. What we're trying to support is FeatureFlagFilters that don't conform to the standard {"name":"name","parameters":{...}}?

The service supports any custom values that the customer wants, or any additional fields the service team wants.

For example we are trying to add a requirement_type field that allows for switching between or/and logic for feature flags. Currently if any modifications are made to the feature flag object any unknown fields are erased which shouldn't happen.

This issue is present in most of the SDKs.

Okay, given this, I think we should add support for "additional properties" throughout the setting. This is fairly standard functionality where a Map<String, Object> is added to a model and handled fluently in serialization and deserialization scenarios.

[mssfang]

Just trying to understand this change a bit more before giving a detailed review. What we're trying to support is FeatureFlagFilters that don't conform to the standard {"name":"name","parameters":{...}}?

The service supports any custom values that the customer wants, or any additional fields the service team wants.
For example we are trying to add a requirement_type field that allows for switching between or/and logic for feature flags. Currently if any modifications are made to the feature flag object any unknown fields are erased which shouldn't happen.
This issue is present in most of the SDKs.

Okay, given this, I think we should add support for "additional properties" throughout the setting. This is fairly standard functionality where a Map<String, Object> is added to a model and handled fluently in serialization and deserialization scenarios.

Offline discussion with Alan. Adding public API to support "unknown properties" which isn't in the swagger is not a good approach. Will keep no change in the SDK public surface. If supporting "unknown properties" in the public API, it should go through the swagger API archiboard and discussion.

[mrm9084]

LGTM now, I would like to test it's change before the release instead of my current work around.