Fix empty state field in /api/deprecated-features/used endpoint

[bas0N]

The /api/deprecated-features/used endpoint was returning an empty state field in the JSON response. This was a regression introduced in #14229, which added the state field to show whether deprecated features are permitted or denied.

The issue was that rabbit_depr_ff_extra:cli_info0/1 always tried to extract the state field with a default empty string, even when rabbit_deprecated_features:list(used) doesn't include a state field (unlike list(all) which does).

This commit fixes the issue by only including the state field when it exists in the feature properties, using maps:find/2 and maps:merge/2 to conditionally add it.

The fix ensures that:

• /api/deprecated-features returns state field with valid values
• /api/deprecated-features/used omits the state field entirely

Tests are updated to verify this behavior.

GitHub issue: #14340

Proposed Changes

This PR fixes a regression introduced in #14229 where the /api/deprecated-features/used endpoint was returning an empty state field in the JSON response.

The Problem:

• PR Show current state of deprecated features (backport #14227) #14229 added a state field to show whether deprecated features are permitted or denied
• The rabbit_deprecated_features:list(all) function includes the state field, but list(used) does not
• However, rabbit_depr_ff_extra:cli_info0/1 always tried to extract the state field with a default empty string, resulting in "state": "" in the response for the /used endpoint

The Solution:

• Modified rabbit_depr_ff_extra:cli_info0/1 to conditionally include the state field only when it exists in the feature properties
• Used maps:find/2 and maps:merge/2 for a more idiomatic Erlang approach
• Updated tests to verify that:
  • /api/deprecated-features includes the state field with valid values (permitted or denied)
  • /api/deprecated-features/used omits the state field entirely

This ensures the API response matches the expected behavior: the state field is either set correctly or omitted, never empty.

Types of Changes

What types of changes does your code introduce to this project?
Put an x in the boxes that apply

• Bug fix (non-breaking change which fixes issue #NNNN)
• New feature (non-breaking change which adds functionality)
• Breaking change (fix or feature that would cause an observable behavior change in existing systems)
• Documentation improvements (corrections, new content, etc)
• Cosmetic change (whitespace, formatting, etc)
• Build system and/or CI

Checklist

Put an x in the boxes that apply.
You can also fill these out after creating the PR.
This is simply a reminder of what we are going to look for before merging your code.

• Mandatory: I (or my employer/client) have have signed the CA (see https://github.com/rabbitmq/cla)
• I have read the CONTRIBUTING.md document
• I have added tests that prove my fix is effective or that my feature works
• All tests pass locally with my changes
• If relevant, I have added necessary documentation to https://github.com/rabbitmq/rabbitmq-website
• If relevant, I have added this change to the first version(s) in release-notes that I expect to introduce it

Further Comments

If this is a relatively large or complex change, kick off the discussion by explaining why you chose the solution
you did and what alternatives you considered, etc.

[michaelklishin]

@bas0N thank you for contributing and the detailed description of the problem and the fix.