Is there an already existing issue for this?

• I have searched the existing issues

Expected behavior

ContentFilteredTopic impl should comply with the participant qos.allocation().content_filter.expression_parameters;
If participantQos.allocation().content_filter.expression_parameters has a valid maximum ,Writer or Reader side should use the max size;
I think fastdds should not skip the qos config and hard code limits;Just use qos content_filter config on the Writer/Reader side ,an d print warning when max size is too long for params to transport.

Current behavior

Reader/Writer side hard code the content_filter config,and only check the participantQos.allocation().content_filter.expression_parameters as a requirement;

Steps to reproduce

/// Allocation configuration for the list of expression parameters
        fastrtps::ResourceLimitedContainerConfig expression_parameters{ 0, 100, 1 };

In ContentFilteredTopicImpl.hpp, eprosima::fastdds::rtps::ContentFilterProperty filter_property is hard code the expression_parameters max size to 100

valid = (num_parameters < 100) && (num_parameters < parameter.expression_parameters.max_size());
ParameterSerializer.hpp parsed expression_parameters max size is harded code must less than 100

Above code will print No warings when the max size greater than 100;Also in the doc,it seems like no limits and just to config;
The doc about contentfilterproperty-allocationconfiguration

Fast DDS version/commit

v2.9.1
v2.10.1
master

Platform/Architecture

Ubuntu Focal 20.04 amd64, Windows 10 Visual Studio 2019

Transport layer

UDPv4, TCPv4

Additional context

No response

XML configuration file

No response

Relevant log output

No response

Network traffic capture

No response