HDDS-11746. Support arbitrary schemas as an option in ozone debug ldb.

[Tejaskriya]

What changes were proposed in this pull request?

ozone debug ldb automatically detects which schema to use for the provided DB based on its name. However, there may be cases where the tool has not been updated to handle a different DB or format. To support these cases before full support is added, a --schema= option is added that allows passing a java class present in the classpath which implements DBDefinition to use as the schema for displaying a provided DB.

What is the link to the Apache JIRA

https://issues.apache.org/jira/browse/HDDS-11746

How was this patch tested?

Added unit test in TestDBDefinitionFactory and integration test in TestLDBCli.
Also added a test in TestDBDefinitionFactory to ensure any DBDefinitions added in the future will be usable through the newly introduced option (i.e., the requires constructor is present).

[kerneltime]

As with any CLI command, please include robot tests.

[adoroszlai]

Thanks @Tejaskriya for the patch.

[adoroszlai]

Thanks @Tejaskriya for updating the patch, LGTM. Few minor improvements suggested on second look.

[Tejaskriya]

Thanks for the review @adoroszlai, I have improved the code following your suggestions!

[Tejaskriya]

@errose28 @adoroszlai I think renaming the option to --dbdefinition would be better. We have a value-schema command which shows a column family's value schema. The "schema" word might be confusing here as we are trying to pass a definition for the whole db, not just a column family.
What do you think?

[adoroszlai]

I think renaming the option to --dbdefinition would be better.

If you would like to change it, I prefer --definition instead of --dbdefinition (or instead of --db-definition, which is a bit more readable, but still clumsy):

• The command is for working with DB, so I find db unnecessary.
• Avoid clash with option --db as a prefix.

[errose28]

@swamirishi this is an implementation of your earlier suggestion in case you want to check it out

[swamirishi]

@Tejaskriya Thanks for working on the patch but I believe the requirement for this kind of generic tooling would be better if we can open random rocksdb tables as long as we have a way to decode value in the classpath.

[swamirishi]

Instead of taking a schema, I would rather take an input of codec to decode the value of a column family. For instance if I want to read snapshot diff DB, the DB doesn't have DB definition since we create new column families on the fly based on the snapdiff job.

[swamirishi]

We should open a rocksdb in read only mode and decode value based on the ValueCodec