include/rocksdb: Configuration validation while opening a DB

[AmnonHanuhov]

RocksDB/Speedb has several knobs that can be controlled via the different Options classes and Options files. Different programs and use cases (such as db_bench, benchmark tool, stress/crash/unit tests) use a different set of default options that are coded into their programs. Because these configurations are built into the tools, it is difficult for customers to reproduce those configurations. Additionally, it is impossible for the software to validate that a customer configuration is part of the configurations that have been tested.

This PR is an effort to create an interface for populating and validating RocksDB/Speedb options, per use case. It also includes a partial implementation of that interface for the use case of validating a user's configuration against the set of configurations checked in db_crashtest.

[AmnonHanuhov]

@mrambacher Should we implement RegisterBuiltinUseCases() and CreateFromString() for DBCrashtestUseCase as well since we have the different classes inheriting from it or should they just be registered/created from the ones we implemented for UseCase

[mrambacher]

@mrambacher Should we implement RegisterBuiltinUseCases() and CreateFromString() for DBCrashtestUseCase as well since we have the different classes inheriting from it or should they just be registered/created from the ones we implemented for UseCase

@AmnonHanuhov There should be only a single CreateFromString. There should probably be a method in DBCrashTestUseCase::RegisterUseCases that registers the implementations. RegisterBuiltinUseCases should then call that method.

[AmnonHanuhov]

@pdillinger Apart from the comments above, generally speaking - does this seem in the right track for what you had in mind?

[pdillinger]

@pdillinger Apart from the comments above, generally speaking - does this seem in the right track for what you had in mind?

Yes, generally in the right direction. Obviously more work to do to have this code generating random "valid" configurations for the crash test.

[AmnonHanuhov]

TODO:

• Support table options
• Get rid of duplicates in the vector remaining in CheckUseCases()
• Give std::unordered_map<std::string, UseCaseConfig> a typename with using.
• Decide whether the bool UseCase::Validate(...) methods are part of the public interface of the UseCase class or not, personally I don't see a reason why the should be, when really what we're using eventually is Status UseCase::ValidateOptions(...).
• Figure out where do we want to place each file, what should be part of the public api etc.

[pdillinger]

This pull request has picked up a bunch of other changes, making it hard to see what is only the configuration validation part.

I guess I can do git diff ea3da8e3caf74b74e0b0c4a306fc5c2891671209..HEAD

[CLAassistant]

Thank you for your submission! We really appreciate it. Like many open source projects, we ask that you all sign our Contributor License Agreement before we can accept your contribution.
4 out of 10 committers have signed the CLA.

:white_check_mark: maxb-io
:white_check_mark: udi-speedb
:white_check_mark: Yuval-Ariel
:white_check_mark: ofriedma
:x: GitHub Runner Bot
:x: ayulas
:x: mrambacher
:x: RoyBenMoshe
:x: git-hulk
:x: AmnonHanuhov

---

GitHub Runner Bot seems not to be a GitHub user. You need a GitHub account to be able to sign the CLA. If you have already a GitHub account, please add the email address used for this commit to your account.
_{You have signed the CLA already but the status is still pending? Let us recheck it.}