Update DB class implementation in cython to v6.11.4 API

[mharshe]

Adds in missing options and functions to make it compatible with the v6.11.4 API for rocksdb.

• Changes options classes to mimic inheritance in original classes (and thus reduced future duplication of code)
• Adds AdvancedOptions
• Adds the Statistics, Metadata, and Types.

Also adds commented methods to the DB class with TODO tag.

Python API is unchanged.

[NightTsarina]

This looks pretty good, and I think I had done some of the same changes a few months ago in a draft I was preparing.. But I am not sure why you say this is needed for v6.11.4, since the tests were already passing? Also, the CI is currently failing on this branch, could you rebase on top of my fixes so all tests are executed?

[mharshe]

What I meant to write was that this updates the classes to match the functionality of v6.11.4. Currently the cython wrappers are missing a lot of functionality and not covering the members available in the rocksdb headers. So the current version offers access to only a subset of the available API.

I've rebased the branch. The workflow is running on my fork and should be ready soon.

[NightTsarina]

Thanks for the explanation, LGTM!

[dato]

Hi, and thank you for these changes.

I suggest that we split this PR in two, taking everything that touches an Option, to a new PR. That will leave a simpler PR here, easy to review.

The reasons I ask for this are the following:

1. the option commits need to be rebased in any case (even if they stay here), because they are not discrete each, and even contradict/undo the work of each other (e.g. 85cef8e introduces CompressionType in advanced_options, but later dec3268 moves it to options). Such unnecessary churn is not good for a single series (PR), that is, we wouldn't want it in main, and it it makes the PR much harder to review.

2. once the history is cleaned up, then there's a bit of tedious work (on my part) of verifying the header files of 6.11.4, and I don't want to delay further Update DB class implementation in cython to v6.11.4 API #4 for that.

3. we'll probably need to update test_options.py, and I have a pending discussion whether advanced_options module should be exposed through options as is now.

At the same time, I don't have the context on what this PR is for: an update motivated exclusively from things/items our team will need in their other projects—or a comprehensive update meant to match upstream-level releases—or just a work-in-progress update, partial for now. I should have perhaps asked for that in the first place, apologies to both!

P.S.: (If point 1 above is done, I would still like to see the code moved to a second PR, but wouldn't insist on it. In other words my Request changes is, mainly/for now, about cleaning up history.)

[dato]

(Just to further clarify, in case I'm not giving all the context needed: e are not going to squash this PR into a one single commit so its history will be directly integrated into main. Your commits are fine in the sense that they reflect the work, but commits meant for mainline need to make sense from a changelog/patch-series point of view, not a particular work path in a particular point in time.)

[mharshe]

Actually I do agree about cleaning up the commit history, just that I ran out of time and created this PR as is. I'll rebase/split/cleanup this on the weekend when i have the time.

The idea of this was to bring up the repo to match upstream release. My understanding is that the target release is at least 6.11.4, so the aim is to bring this up to that version, step by step, and eventually support TransactionDB.

As the changes are too many, I started with the DB class and options first. I might have to reorder the PRs because the DB class depends on many other classes/objects and options class needs to be updated first. I'll convert this to a draft PR so that it is clear that the other ones are to be looked at first.

[mharshe]

This PR updates the cython backend but does not change the Python API for the DB class. Some dummy methods are added but they remain commented. As the python API is unchanged, no unit tests are added for testing the DB class.