Migrate from deprecated substreams-sink to integrated substreams/sink package

[Copilot]

The repository was using the deprecated standalone github.com/streamingfast/substreams-sink library. This migrates to the integrated github.com/streamingfast/substreams/sink package per the migration guide.

Changes

API Signature Updates

• NewFromViper: Removed endpoint and blockRange parameters (now handled via flags), added userAgent parameter (dynamically uses version from main CLI)
• BlockRange(): Replaced with StartBlock() and StopBlock() methods
• ReadManifestAndModuleAndBlockRange: Updated to ReadManifestAndModule

Flag Management

• Block range now specified via --start-block and --stop-block flags
• Endpoint now specified via --endpoint flag with automatic network inference from manifest
• Used deprecated FlagIgnore API for minimal migration impact
• Resolved flag conflicts in from-proto command by excluding overlapping sink flags
• Added explanatory comments for flag bridging between commands and substreams/sink library

Backward Compatibility

• Maintained CLI compatibility: The run command continues to accept the original [<start>:<stop>] block range syntax as a positional argument
• Block range argument is automatically parsed and bridged to the new flag-based system
• No breaking changes for existing users

Example

// Before
sink, err := sink.NewFromViper(
    cmd,
    supportedOutputTypes,
    endpoint,           // explicit endpoint
    manifestPath,
    moduleName,
    "1000:2000",       // block range string
    zlog,
    tracer,
)

// After
sink, err := sink.NewFromViper(
    cmd,
    supportedOutputTypes,
    manifestPath,
    moduleName,
    fmt.Sprintf("substreams-sink-sql/%s", version), // userAgent from CLI version
    zlog,
    tracer,
)
// Endpoint and block range now controlled via --endpoint, --start-block, --stop-block flags
// Original CLI syntax (e.g., "run <dsn> <manifest> 100:200") still works for backward compatibility

Migration Approach

Minimal migration path using deprecated but compatible APIs to reduce surface area of changes while maintaining full backward compatibility with existing CLI usage patterns.

---

💡 You can make Copilot smarter by setting up custom instructions, customizing its development environment and configuring Model Context Protocol (MCP) servers. Learn more Copilot coding agent tips in the docs.

[maoueh]

We can probably pull the version from the main CLI directly somehow.

[Copilot]

Updated to use the version variable from main.go (commit 690d940). Now uses fmt.Sprintf("substreams-sink-sql/%s", version) which will be populated via ldflags at build time.

[maoueh]

Could we remain compatible with previous CLI way, I would like to avoid a breaking change for users.

[Copilot]

Backward compatibility restored (commit 690d940). The run command now accepts [<start>:<stop>] block range as before. The code detects if the third argument contains ':' to determine if it's a block range and parses it accordingly, maintaining the original CLI behavior.

[maoueh]

Is this equivalent to previous code?

[Copilot]

Yes, it's equivalent (commit 690d940). Added a comment explaining that bstream.ParseRange handles the same block range format that the old sink.ReadBlockRange did (e.g., "100:200", "100:", ":200"). The only difference is the API surface changed but the parsing behavior remains the same.

[maoueh]

It would be better for all those funky cmd.Flags().Set(...) call to comment that this is to bridge with substreams/sink library to it can work properly.

Adjust for such all changes in the PR.

[Copilot]

Added explanatory comments for all flag bridging code (commit 690d940). Comments now clarify that these cmd.Flags().Set() calls bridge custom flags with the substreams/sink library's expected flags.