Fix large sync sessions by reusing the same session

[avinassh]

Currently, we have a bug where each push request creates a new sync session in the server. Each push request can send up to 128 frames.
However, if a transaction spans more than 128 frames, then it needs to reuse the same sync session. Otherwise, the first push will succeed, but the rest of the pushes will fail due to the write lock held by the previous session.

This patch reuses the sync session. The way we do this is by using batons. If the server sends a baton, then we pass it back. Reusing the same baton ensures that we are using the same sync session.

[Copilot]

Pull Request Overview

This PR fixes a bug by reusing the same sync session during consecutive push requests through the introduction of baton handling. The key changes include:

• Updated the push_frames API to accept an optional baton parameter and return a PushFramesResult struct.
• Adjusted test cases in libsql/src/sync/test.rs to align with the new return type.
• Modified the sync session logic in libsql/src/sync.rs to reuse the baton for subsequent push requests.

Reviewed Changes

Copilot reviewed 2 out of 2 changed files in this pull request and generated no comments.

File	Description
libsql/src/sync/test.rs	Updated tests to provide the baton parameter and assert on max_frame_no.
libsql/src/sync.rs	Revised the push_frames API and related logic to support baton reuse.

Comments suppressed due to low confidence (2)

libsql/src/sync/test.rs:33

• Consider adding tests that simulate scenarios where the server returns a defined baton to ensure that baton reuse works correctly.

assert_eq!(durable_frame.max_frame_no, 0); // First frame should return max_frame_no = 0

libsql/src/sync.rs:200

• Consider adding an inline comment explaining the purpose of appending the baton to the URI, which reinforces the session reuse mechanism.

if let Some(ref baton) = baton { uri.push_str(&format!("/{}", baton)); }

[penberg]

@avinassh This is similar to #2014, no? I am happy to use your variant, just wanted to make sure you're fixing the same issue?

[avinassh]

@penberg indeed it is same, I wasn't aware that you had a patch already