[gql] Watermark task reads from watermarks table, use watermarks for Event::paginate

[wlmyng]

Description

Watermark task now reads from watermarks table instead of checkpoints table. This is used for Event::paginate, so we can correctly bound the available range of data

Test plan

Pointed local graphql to current mainnet db. Ran the query below:

query Event {
  events(filter:{eventType:"0x3::validator::StakingRequestEvent"})
  {
    pageInfo {
      hasNextPage
      endCursor
    }
    nodes {
      sendingModule {
        name
        package {
          address
        }
      }
      sender {
        address
      }
      contents {
        json
      }
      
      timestamp
    }
  }
}

Received expected page of results instead of erroneous result,

{
  "data": {
    "events": {
      "pageInfo": {
        "hasNextPage": true,
        "endCursor": null
      },
      "nodes": []
    }
  }
}

---

Release notes

Check each box that your changes affect. If none of the boxes relate to your changes, release notes aren't required.

For each box you select, include information after the relevant heading that describes the impact of your changes that a user might notice and any actions they must take to implement updates.

• Protocol:
• Nodes (Validators and Full nodes):
• gRPC:
• JSON-RPC:
• GraphQL:
• CLI:
• Rust SDK:

[vercel]

The latest updates on your projects. Learn more about Vercel for Git ↗︎

Name	Status	Preview	Comments	Updated (UTC)
sui-docs	✅ Ready (Inspect)	Visit Preview	💬 Add feedback	Feb 11, 2025 8:54pm

2 Skipped Deployments

Name	Status	Preview	Comments	Updated (UTC)
multisig-toolkit	⬜️ Ignored (Inspect)	Visit Preview		Feb 11, 2025 8:54pm
sui-kiosk	⬜️ Ignored (Inspect)	Visit Preview		Feb 11, 2025 8:54pm

[amnn]

The main body of this change looks good, but I think there's a subtle issue with the change to Event::paginate when a cursor supplies its own consistency cursor -- PTAL!

[amnn]

In general checkpoint_viewed_at and Watermark are not always interchangeable (you get into issues if this function is used to handle a paginated query that is nested in some other paginated query).

Today, I don't think we use this function for that, (I can see from this PR that you only needed to update a top-level field on Query), but we generally expect functions called paginate to work like that.

Given there's only one call-site, could we shift the boundary slightly here so that we accept both a checkpoint_viewed_at and a tx_lo, and then go on from there?

[amnn]

This change behaves differently if there is a cursor_viewed_at, right?