Bug fix: Idempotency shouldn't apply for report generation

[Kandarimegha]

Type of Change

• Bug fix
• New feature
• Breaking change
• Documentation update

Description

This PR introduces enhancements and fixes to the reports_workflow_manager module to improve report creation, validation, and time range filter handling.
It ensures better compatibility with the DNAC API schema and improves user flexibility when defining report parameters.

Bug Fix

Brief Description:
Fixed issues related to incorrect time range filter serialization and report name duplication when a report already exists.

Root Cause:

• When new_report was intended to create a duplicate with a timestamp, the logic did not handle this properly, leading to conflicts with existing report names.

Fix Implemented:

• Updated _process_time_range_filter() to correctly format the value as a single dictionary instead of a list, matching the DNAC API model.
• Implemented validation for time_range_option, start_date_time, end_date_time, and time_zone fields, including IANA timezone verification.
• Enhanced report creation logic (_create_new_report) to append a timestamp suffix when new_report: true and a report with the same name already exists.

Enhancement

Brief Description:

• Added support for new_report parameter and improved validation for time range filters.

Enhancement Description:

• Introduced a new boolean parameter new_report in the playbook spec to control whether a new report should be created if one already exists.
• Enhanced input validation in validate_input() to include additional schema checks for time_range_option, start_date_time, end_date_time, and time_zone.
• Improved logging and structured error handling for better traceability.
• Updated documentation and example playbooks to demonstrate new and custom time range configurations.

Testing Done:

• [] Manual testing
• [] Unit tests
• [] Integration tests

Test cases covered: [Mention test case IDs or brief points]

Checklist

• My code follows the style guidelines of this project
• I have performed a self-review of my own code
• I have commented my code, particularly in hard-to-understand areas
• I have made corresponding changes to the documentation
• My changes generate no new warnings
• I have added tests that prove my fix is effective or that my feature works
• New and existing unit tests pass locally with my changes
• Any dependent changes have been merged and published in downstream modules
• All the sanity checks have been completed and the sanity test cases have been executed

Ansible Best Practices

• Tasks are idempotent (can be run multiple times without changing state)
• Variables and secrets are handled securely (e.g., using ansible-vault or environment variables)
• Playbooks are modular and reusable
• Handlers are used for actions that need to run on change

Documentation

• All options and parameters are documented clearly.
• Examples are provided and tested.
• Notes and limitations are clearly stated.

Screenshots (if applicable)

Notes to Reviewers

[maaliaj]

• A very minor issue.

[maaliaj]

can we add new_report: true or false in one of the examples in the input file?