feat: Implement historical pricing for message cost recalculation

[amalcaraz]

Summary

Implements historical pricing support for message cost recalculation, ensuring costs are calculated using the pricing models that were active when messages were originally created.

Key Changes

🔧 New Pricing Timeline System

• Created pricing_utils.py with reusable pricing model utilities
• Implemented get_pricing_timeline() to track pricing changes over time
• Added proper cumulative merging of pricing aggregate elements

⚡ Enhanced Cost Recalculation

• Updated /api/v0/price/recalculate endpoint to use historical pricing
• Messages processed chronologically (oldest to newest) with correct pricing timeline
• Maintains pricing model state efficiently during batch processing

🔄 Migration Refactoring

• Refactored migration 0033_1c06d0ade60c to use reusable build_default_pricing_model()
• Removed hardcoded pricing dictionary in favor of DEFAULT_PRICE_AGGREGATE constant
• Improved maintainability and consistency

🧪 Comprehensive Testing

• Added 60+ test cases covering timeline functionality, API endpoints, and migration compatibility
• Tests ensure historical accuracy and proper error handling
• Integration tests verify end-to-end pricing application

API Endpoints

• POST /api/v0/price/recalculate - Recalculate all message costs with historical pricing
• POST /api/v0/price/{item_hash}/recalculate - Recalculate specific message costs

Auth methods

The new endpoints have a basic token auth system with signed tokens that will expire after 5 minutes

• Create a new token using the helper script:
  ./deployment/scripts/auth_token.py --create-token
• Include the X-Auth-Token header with the base64 token generated by the script

Benefits

✅ Historical Accuracy: Costs calculated using pricing active when messages were created✅ Performance: Efficient timeline processing without repeated DB queries✅ Maintainability:
Reusable pricing utilities reduce code duplication✅ Robustness: Comprehensive error handling and extensive test coverage

[nesitor]

I think that we shouldn't have to modify a migration already executed on the rest of the CCNs to prevent unconsistencies on the database.

[amalcaraz]

We are still using a constant (DEFAULT_PRICE_AGGREGATE) with the same hardcoded default pricing than before. The only change is a type conversion from Dict[str, dict] to Dict[ProductPriceType, ProductPricing] which is the type that the migration uses

[nesitor]

Anyway, I think that we don't have to touch an already executed migration, just to be sure that doesn't crash and for keeping the same migration history on all the CCNs.

[nesitor]

Everything looks good except the migration change, that I prefer to leave as is.