support querying next snapshot after a timestamp

[isegall-da]

Will be useful for streaming ACS snapshots to S3

Pull Request Checklist

Cluster Testing

• If a cluster test is required, comment /cluster_test on this PR to request it, and ping someone with access to the DA-internal system to approve it.
• If a hard-migration test is required (from the latest release), comment /hdm_test on this PR to request it, and ping someone with access to the DA-internal system to approve it.

PR Guidelines

• Include any change that might be observable by our partners or affect their deployment in the release notes.
• Specify fixed issues with Fixes #n, and mention issues worked on using #n
• Include a screenshot for frontend-related PRs - see README or use your favorite screenshot tool

Merge Guidelines

• Make the git commit message look sensible when squash-merging on GitHub (most likely: just copy your PR description).

[rautenrieth-da]

Will be useful for streaming ACS snapshots to S3

Code looks fine, but why are we adding a new HTTP endpoint? Is the process that uploads to S3 going to implemented outside of scan? If it will live inside scan, then we don't need a new endpoint, no?

[rautenrieth-da]

This is different from the /v0/state/acs/snapshot-timestamp endpoint, which only looks at snapshots from exactly the given migration id.

[isegall-da]

TBH, I think that the semantics in the existing one is less useful. People don't really care about migration IDs, it's almost an implementation detail. They just want the previous/next snapshot from a specific timestamp.

[rautenrieth-da]

A bit complicated for a table with only thousands of rows, but should make optimal use of the available primary key index.

[isegall-da]

yup, that was my thinking exactly

[isegall-da]

why are we adding a new HTTP endpoint?

Mostly so that I can call it in the integration test TBH.
But I'd say "why not"? Do we have any reason to believe that people want to query "before" more than they want "after"?

[isegall-da]

why are we adding a new HTTP endpoint?

Mostly so that I can call it in the integration test TBH. But I'd say "why not"? Do we have any reason to believe that people want to query "before" more than they want "after"?

@rautenrieth-da @ray-roestenburg-da I'm going to merge this as-is. Please shout if you think that having this endpoint is a mistake, we have until the next release to remove it easily if so.