feat: new command to restore ksqlDB command topic backups

[spena]

Description

What behavior do you want to change, why, how does your patch achieve the changes?
Fixes #6286

This is a new command that helps to restore command topic backups:

NAME
        ksql-restore-metadata - KSQL Restore Metadata

SYNOPSIS
        ksql-restore-metadata --config-file <configFile> [ {-h | --help} ]
                [ {--yes | -y} ] [--] <backup-file>

OPTIONS
        --config-file <configFile>
            A file specifying configs for the KSQL Server, KSQL, and its
            underlying Kafka Streams instance(s). Refer to KSQL documentation
            for a list of available configs.

        -h, --help
            Display help information

        --yes, -y
            Automatic "yes" as answer to prompt and run non-interactively.

        --
            This option can be used to separate command-line options from the
            list of arguments (useful when arguments might be mistaken for
            command-line options)

        <backup-file>
            A file specifying the file that contains the metadata backup.

With default options, the command prompts the user to answer if continuing with the restore process or not. This is required to avoid an accidental restore process (the option -y will assume "yes" as the answer).

./bin/ksql-restore-command-topic --config-file <config-file> <backup-file>
Restoring the command topic will DELETE your actual metadata.
Continue [yes or no] (default: no)? 

The restoration process displays timing information in the console to let the user know how much time it took to restore the command topic:

./bin/ksql-restore-command-topic --config-file <config-file> <backup-file> --yes
Loading backup file ...
Backup (1 records) loaded in memory in 347 ms.

Restoring command topic ...
Restore process completed in 1164 ms.

You need to restart the ksqlDB server to re-load the command topic.

Testing done

Describe the testing strategy. Unit and integration tests are expected for any behavior changes.
Added unit tests
Verified manually

Reviewer checklist

• Ensure docs are updated if necessary. (eg. if a user visible feature is being added or changed).
• Ensure relevant issues are linked (description should include text like "Fixes #")

[stevenpyzhang]

What should we do in the case that the restore is interrupted/fails in the middle of the process? We'll have a command topic with only a partial set of commands. I'm wondering if we should just delete this incomplete command topic.

[stevenpyzhang]

I think we might actually need to use transactions to restore the command topic.
When the command topic is produced to normally, there are transactional messages produced to the command topic that take up offsets. If we restore without using transactions, this could mean the restored command topic will have a lower offset than the original command topic, that could result in query id's conflicting since we generate query id based on the offset.

For example, there are 10 command records in command topic (offset would be 15-20 potentially)
After restoring 10 command records using this tool, the offset would be 10.

We don't have to go through validation/wait for the CommandRunner like we do in DistributingExecutor so the protocol here can be much simpler.

init transaction
for each command in the backupfile
   begin transaction
   enqueue command
   commit transaction
close producer

[stevenpyzhang]

nit: we shouldn't check these in if this is a specific checkstyle error to your local environment

[stevenpyzhang]

LGTM, would it be possible to also add an integration test as part of this pr? We could start up a server with backups enabled, issue a bunch of DDL statements, stop server, delete command topic, run the executable to restore, start up new server and verify the metastore matches what it was previously.

[spena]

Added an integration tests