Add sync API for transactional client

[odecode]

For issue #289 a synchronous API for transactional client.

I have programmed a fair bit but new to OSS and Rust. I consulted AI heavily for this to try and get an understanding of what this part of the project is about and how it works, but I tried using it a teacher rather than just "vibe coding".

[ti-chi-bot]

[APPROVALNOTIFIER] This PR is NOT APPROVED

This pull-request has been approved by:
Once this PR has been reviewed and has the lgtm label, please assign niedhui for approval. For more information see the Code Review Process.
Please ensure that each of them provides their approval before proceeding.

The full list of commands accepted by this bot can be found here.

Details

Needs approval from an approver in each of these files:

• OWNERS

Approvers can indicate their approval by writing /approve in a comment
Approvers can cancel approval by writing /approve cancel in a comment

[ti-chi-bot]

Welcome @odecode!

It looks like this is your first PR to tikv/client-rust 🎉.

I'm the bot to help you request reviewers, add labels and more, See available commands.

We want to make sure your contribution gets all the attention it needs!



Thank you, and welcome to tikv/client-rust. 😃

[Copilot]

Pull request overview

This PR adds a synchronous API wrapper for the TiKV transactional client to address issue #289. The implementation provides blocking alternatives to the existing async transaction APIs.

Changes:

• Introduced SyncTransactionClient, SyncTransaction, and SyncSnapshot structs that wrap their async counterparts
• Each sync type contains an Arc-wrapped Tokio runtime and uses block_on to execute async operations synchronously
• Added comprehensive integration tests mirroring the async test patterns

Reviewed changes

Copilot reviewed 7 out of 7 changed files in this pull request and generated 6 comments.

Show a summary per file

File	Description
src/transaction/sync_client.rs	New synchronous client wrapper providing blocking transaction operations
src/transaction/sync_transaction.rs	Synchronous transaction wrapper that blocks on async transaction methods
src/transaction/sync_snapshot.rs	Synchronous snapshot wrapper for read-only operations
src/transaction/mod.rs	Module declarations for new sync components
src/lib.rs	Public API exports for sync types
tests/sync_transaction_tests.rs	Comprehensive integration tests covering all sync APIs
tests/common/mod.rs	Added init_sync() helper for synchronous test setup

---

💡 Add Copilot custom instructions for smarter, more guided reviews. Learn how to get started.

[odecode]

Thank you for the review comments, I have made changes according to the comments

[Copilot]

Pull request overview

Copilot reviewed 7 out of 7 changed files in this pull request and generated 3 comments.

---

💡 Add Copilot custom instructions for smarter, more guided reviews. Learn how to get started.

[odecode]

I have made changes requested by the review comments

[Copilot]

Pull request overview

Copilot reviewed 7 out of 7 changed files in this pull request and generated 1 comment.

---

💡 Add Copilot custom instructions for smarter, more guided reviews. Learn how to get started.

[Copilot]

The init_sync function creates a temporary Tokio runtime just to initialize the test environment. This creates a nested runtime situation where init_sync creates a runtime to call init, then that runtime is dropped, and then each test creates its own runtime through sync_client. While this works, it's inefficient and could potentially lead to resource issues. Consider creating a single runtime that persists for the duration of testing, or restructuring init_sync to avoid the temporary runtime creation.

Suggested change

	tokio::runtime::Runtime::new()?.block_on(init())
	if let Ok(handle) = tokio::runtime::Handle::try_current() {
	handle.block_on(init())
	} else {
	tokio::runtime::Runtime::new()?.block_on(init())
	}