feat: Propagate license ID across feeds sharing the same license URL

[davidgamez]

Summary:

This pull request introduces a new feature for propagating license IDs to multiple feeds that share the same normalized license URL, along with supporting API documentation and implementation changes. Additionally, it updates the OpenAPI schema to support this functionality and adds new request/response models for the API. There are also minor documentation improvements and cleanup of hash descriptions in the API schema.

License Propagation Feature:

• Added a new function propagate_license_by_url in license_utils.py to propagate a license ID to all non-deprecated GTFS/GTFS-RT feeds sharing the same normalized license URL, with support for dry-run and override modes. The function returns a detailed result describing affected feeds.
• Integrated license propagation into feed creation and update flows in feeds_operations_impl.py. When propagate_license is set to true in the request, the license ID is propagated to all matching feeds after creation or update. [1] [2] [3]

API and OpenAPI Documentation:

• Added a new API endpoint /v1/operations/licenses:propagate_match to trigger license propagation, with new request and response schemas (PropagateLicenseRequest, PropagateLicenseResponse, PropagateLicenseAffectedFeed). [1] [2]
• Extended feed creation and update request schemas to include a propagate_license boolean property, allowing clients to request license propagation as part of those operations. [1] [2] [3] [4]

Supporting Code and Models:

• Registered new generated model files for the propagate license API in the codebase.

Documentation and Schema Cleanup:

• Cleaned up hash field descriptions in the OpenAPI schema, removing references to MD5 and clarifying hash usage. [1] [2]

Minor Documentation Enhancements:

• Added clarifying comments and improved enum documentation for feed status and data types. [1] [2]

These changes collectively enable operators to easily propagate license information across multiple feeds with a single action, improving data consistency and reducing manual updates.

Expected behavior:

Explain and/or show screenshots for how you expect the pull request to work in your testing (in case other devices exhibit different behavior).

Testing tips:

Provide tips, procedures and sample files on how to test the feature.
Testers are invited to follow the tips AND to try anything they deem relevant outside the bounds of the testing tips.

Please make sure these boxes are checked before submitting your pull request - thanks!

• Run the unit tests with ./scripts/api-tests.sh to make sure you didn't break anything
• Add or update any needed documentation to the repo
• Format the title like "feat: [new feature short description]". Title must follow the Conventional Commit Specification(https://www.conventionalcommits.org/en/v1.0.0/).
• Linked all relevant issues
• Include screenshot(s) showing how this pull request works and fixes the issue(s)

[emmambd]

Shiny! What is the workflow of this change @davidgamez? Say in Retool we insert the same license URL into a feed, and the URL matches 3 other feeds. What needs to happen for the propagation to take place?

[davidgamez]

Shiny! What is the workflow of this change @davidgamez? Say in Retool we insert the same license URL into a feed, and the URL matches 3 other feeds. What needs to happen for the propagation to take place?

You just need to select the checkbox to propagate the license