feat: horizon support (Semiotic branch + fixes)

[tmigone]

Note: This PR contains changes from Semiotic PR for horizon support with additional fixes. Original PR description below.

Horizon Gateway Upgrade

This horizon gateway provides TAP v2 receipt generation.

Overview

This is a horizon-ready gateway that replaces TAP receipt generation with TAP v2 receipts on the existing edgeandnode/gateway.

Key Changes from Pre-Horizon Gateway

TAP Protocol Support

• Pre-Horizon: Only supports TAP v1 receipts
• Horizon: Generates TAP v2 receipts, can process v1 receipts for redemption

Receipt Generation

• Upstream: Uses create_receipt(allocation, fee) for v1 receipts
• Horizon: Uses create_receipt(allocation, fee, payer, data_service, service_provider) for v2 receipts

ID Types

• Pre-Horizon: Uses AllocationId for receipt generation and payment tracking
• Horizon: Uses AllocationId for receipt generation, supports both types for processing

Receipt Structure

v1 Receipts (Pre-Horizon):

• allocation_id: Address of the allocation
• timestamp_ns: Timestamp in nanoseconds
• nonce: Random nonce
• value: Fee amount in wei

v2 Receipts (Horizon):

• collection_id: Collection identifier (derived from allocation_id)
• payer: Address of the payer
• data_service: Address of the data service
• service_provider: Address of the service provider
• timestamp_ns: Timestamp in nanoseconds
• nonce: Random nonce
• value: Fee amount in wei

Migration from Pre-Horizon

For Operators

1. Dependencies: Updated tap_graph to support v2 receipts
2. Configuration: No configuration changes needed
3. Deployment: Requires horizon contracts to be deployed on the network
4. Compatibility: Can still process existing v1 receipts

For Indexers

1. Receipt Processing: Must support v2 receipt processing
2. Collection IDs: Should use collection IDs instead of allocation IDs
3. Backward Compatibility: Can still redeem any existing v1 receipts

[Theodus]

Still working through this review. I've gone ahead and removed all the extra logging that should not be in here.

[Theodus]

What are these tests doing in this module?

[tmigone]

hmm not sure, they probably should be in src/receipts.rs

[tmigone]

I've removed them in ce5d5ed, did not look like they were useful.

[Theodus]

maintains backward compatibility for processing existing TAP v1 receipts but it won't generate new ones

What does it mean to maintain backward compatibility, if we're not generating the TAP v1 receipts? I don't think there is anything else we would be doing with them.

[tmigone]

Not sure what Joseph meant with that, my guess is that it refers to the tap-aggregator's ability to still process TAP v1 receipts, but that component is not on this repo so I removed that line 80faf65.

[Theodus]

The initial comment on this PR should also be updated.

[Theodus]

LGTM. Thanks!

[Theodus]

Marking as DO NOT MERGE, since this is not being deployed to mainnet yet. I've started a build for a docker image tagged sha-8e05474 for deploying to testnet when we are ready.