Added Redis cluster topology refresh options for Jedis implementation

[ShvaykaD]

Pull Request description

Issue: #180

Note:
Currently, the project has separate configurations for both Lettuce and Jedis to support cluster topology refresh options. This is a temporary arrangement. In the future, we plan to standardize and use Lettuce exclusively across the entire project.

New configuration:

# Redis lettuce configuration parameters
lettuce:
  ...
  config:
    ...
    cluster:
      topology-refresh:
        # Enables or disables periodic cluster topology updates.
        # Useful for Redis Cluster setup to handle topology changes,
        # such as node failover, restarts, or IP address changes
        enabled: "${REDIS_LETTUCE_CLUSTER_TOPOLOGY_REFRESH_ENABLED:false}"
        # Specifies the interval (in seconds) for periodic cluster topology updates
        period: "${REDIS_LETTUCE_CLUSTER_TOPOLOGY_REFRESH_PERIOD_SEC:60}"

# Redis jedis configuration parameters
jedis:
  cluster:
    topology-refresh:
      # Enables or disables periodic cluster topology updates.
      # Useful for Redis cluster setup to handle topology changes,
      # such as node failover, restarts, or IP address changes
      enabled: "${REDIS_JEDIS_CLUSTER_TOPOLOGY_REFRESH_ENABLED:false}"
      # Specifies the interval (in seconds) for periodic cluster topology updates
      period: "${REDIS_JEDIS_CLUSTER_TOPOLOGY_REFRESH_PERIOD_SEC:60}"

Additional ctx:

Please note that the configuration structure might change following the PR review process. We recommend revisiting and reviewing the final configuration after the official release to ensure it aligns with the expected requirements.

General checklist

• You have reviewed the guidelines document.
• Labels that classify your pull request have been added.
• The milestone is specified and corresponds to fix version.
• Description references specific issue.
• Description contains human-readable scope of changes.
• Description contains brief notes about what needs to be added to the documentation.
• No merge conflicts, commented blocks of code, code formatting issues.
• Changes are backward compatible or upgrade script is provided.

Front-End feature checklist

• Screenshots with affected component(s) are added. The best option is to provide 2 screens: before and after changes;
• If you change the widget or other API, ensure it is backward-compatible or upgrade script is present.

Back-End feature checklist

• Added corresponding unit and/or integration test(s). Provide written explanation in the PR description if you have failed to add tests.
• If new dependency was added: the dependency tree is checked for conflicts.