[g175:3] graph/db: continue prepping `models` for V2 data

[ellemouton]

This PR continues the preparation work for Gossip V2 support by refactoring the graph database layer to use versioned constructors for ChannelEdgeInfo and ChannelAuthProof. This ensures that channel edge information is properly typed by gossip version and sets the foundation for handling both V1 and V2 channels in the graph database.

Key Changes

• Introduce V1-specific constructors: Replace direct struct initialization of ChannelEdgeInfo and ChannelAuthProof with versioned constructors (models.NewV1Channel() and models.NewV1ChannelAuthProof())
• Decouple auth proof from announcement creation: Move auth proof attachment to happen before calling netann.CreateChanAnnouncement(), simplifying the function signature and making the data flow more explicit
• Add helper method: Implement ToChannelAnnouncement() on ChannelEdgeInfo to convert stored channel info into wire-format announcements
• Consistent optional fields: Use functional options pattern for optional channel fields (capacity, proof, features, etc.)
• Update test infrastructure: Refactor all test code to use the new constructors, ensuring type safety across the test suite

Motivation

This change prepares the codebase for Gossip V2 by:

1. Making the gossip version explicit at channel creation time
2. Ensuring all channel edge information is properly validated through constructors
3. Preventing accidental mixing of V1 and V2 channel data
4. Providing a clear migration path when V2 channels are introduced

Part of https://github.com/lightningnetwork/lnd/issues/10293

[gemini-code-assist[bot]]

Summary of Changes

Hello @ellemouton, I'm Gemini Code Assist[^1]! I'm currently reviewing this pull request and will post my feedback shortly. In the meantime, here's a summary to help you and other reviewers quickly get up to speed!

This pull request advances the ongoing effort to prepare the system for V2 channel data models. It involves a significant refactoring of fundamental channel-related data structures to be version-aware, introducing new, more robust ways to construct and interact with channel information. The changes propagate throughout the codebase, updating existing components to align with the new model. Furthermore, the database schema is proactively modified to accommodate future V2 channel data, ensuring a smooth transition when V2 is fully implemented.

Highlights

• Refactored Channel Models for V2 Readiness: The core ChannelAuthProof and ChannelEdgeInfo structs have been significantly refactored to support versioning, laying the groundwork for V2 channel data. ChannelAuthProof now includes a Version field and uses fn.Option[[]byte] for signatures, differentiating between V1 (four signatures) and V2 (single Schnorr signature). ChannelEdgeInfo also gains a Version field and utilizes fn.Option[route.Vertex] for Bitcoin keys.
• New Constructors and Helper Methods: New constructors like NewV1ChannelAuthProof and NewV1Channel have been introduced to streamline the creation of V1 channel models. Additionally, helper methods such as NodeSig1(), BitcoinSig1(), FundingPKScript(), and ToChannelAnnouncement() were added to ChannelAuthProof and ChannelEdgeInfo for easier and safer access to channel data.
• Widespread Codebase Updates: Numerous files across various modules (e.g., autopilot, discovery, graph, lnrpc, netann, routing, rpcserver) have been updated to integrate and utilize the new version-aware channel models, constructors, and helper methods. This ensures compatibility and consistency with the refactored data structures.
• Database Schema and Logic Adjustments: The database schema (sqldb/sqlc/graph.sql) has been extended to include new fields (signature, funding_pk_script, merkle_root_hash) in the graph_channels table, anticipating the storage requirements for V2 channel data. Corresponding database logic in graph/db/kv_store.go and graph/db/sql_store.go has been updated with version checks, currently enforcing V1 support while preparing for V2.

Using Gemini Code Assist

The full guide for Gemini Code Assist can be found on our documentation page, here are some quick tips.

Invoking Gemini

You can request assistance from Gemini at any point by creating a comment using either /gemini <command> or @gemini-code-assist <command>. Below is a summary of the supported commands on the current page.

Feature	Command	Description
Code Review	/gemini review	Performs a code review for the current pull request in its current state.
Pull Request Summary	/gemini summary	Provides a summary of the current pull request in its current state.
Comment	@gemini-code-assist	Responds in comments when explicitly tagged, both in pull request comments and review comments.
Help	/gemini help	Displays a list of available commands.

Customization

To customize Gemini Code Assist for GitHub experience, repository maintainers can create a configuration file and/or provide a custom code review style guide (such as PEP-8 for Python) by creating and adding files to a .gemini/ folder in the base of the repository. Detailed instructions can be found here.

Limitations & Feedback

Gemini Code Assist may make mistakes. Please leave feedback on any instances where its feedback is incorrect or counter productive. You can react with :thumbsup: and :thumbsdown: on @gemini-code-assist comments. If you're interested in giving your feedback about your experience with Gemini Code Assist for Github and other Google products, sign up here.

You can also get AI-powered code generation, chat, as well as code reviews directly in the IDE at no cost with the Gemini Code Assist IDE Extension.

[^1]: Review the Privacy Notices, Generative AI Prohibited Use Policy, Terms of Service, and learn how to configure Gemini Code Assist in GitHub here. Gemini can make mistakes, so double check it and use code with caution.

[lightninglabs-deploy]

@ellemouton, remember to re-request review from reviewers when ready