feat: support limit WriteBatch size

[AntiTopQuark]

relate to https://github.com/apache/kvrocks/issues/2284

Added the ability to limit the size of WriteBatch operations in RocksDB to control memory usage effectively.

[git-hulk]

@AntiTopQuark Thanks for your efforts. Would you mind adding a Go test case for this?

[AntiTopQuark]

@AntiTopQuark Thanks for your efforts. Would you mind adding a Go test case for this?

Sure, I will complete this task later.

[AntiTopQuark]

While adding cases, it was found that there were no corresponding error messages, so error codes were added and reported in many places involving batch processing

[git-hulk]

While adding cases, it was found that there were no corresponding error messages, so error codes were added and reported in many places involving batch processing

Yes, that makes sense.

[git-hulk]

@AntiTopQuark One comment inline, rest are good to me. Could anyone also have a look at this PR? @PragmaTwice @torwig @caipengbo @mapleFU

[sonarqubecloud[bot]]

Quality Gate passed

Issues
42 New issues
0 Accepted issues

Measures
0 Security Hotspots
56.7% Coverage on New Code
4.4% Duplication on New Code

See analysis details on SonarCloud

[git-hulk]

Also cc @PragmaTwice

Do we need some macro like RETURN_NOT_OK, RETURN_NOT_OK_FROM_ROCKSDB?

@mapleFU @AntiTopQuark RETURN_IF_ERR is also good for this?

[mapleFU]

I think it's good. Another problem is that we may need type cast between Status and rocksdb::Status. We can make a new issue here.

[git-hulk]

Yes, let's discuss this in new issue.

[PragmaTwice]

Also cc @PragmaTwice

Do we need some macro like RETURN_NOT_OK, RETURN_NOT_OK_FROM_ROCKSDB?

Nope. They can be done by GET_OR_RET.

[mapleFU]

Nope. They can be done by GET_OR_RET.

So GET_OR_RET can also handle the case for pure "Status"?

Besides, what about err from rocksdb?