Implement CLI for restore

[mdedetrich]

About this change - What it does

This PR implements CLI for the restore portion of guardian.

Why this way

The structure of the PR is pretty much the same as the earlier one that implemented CLI for backup (see #83) with some additional notes/exceptions

• A

  try backup.Main.main(args.toArray)
  catch {
    case _: Throwable =>
  }

  was added to the CliSpec tests for restore and the already existing backup. This is necessary because the Main part of
  Restore will throw an exception when initialized because not all of the data passed into main test actually exists (i.e.
  backup-bucket doesn't actually exist in S3). Note that the purpose of these tests is to see if the command line arguments are
  being correctly passed into the application's configuration, its NOT testing that the application actually runs correctly with
  those arguments (thats for proper end2end tests which exist elsewhere)
  • Technically speaking the try/catch clause is not necessary for the backup because it happens to gracefully shutdown without an exception however this is an internal detail and so I added the try/catch clause to backup for consistency reasons
• If for whatever reason the configuration isn't initialized in the tests we fail with Expected an App to be initialized. This change was done both for new Restore and current Backup. Without this change the tests wouldn't actually fail in this case as expected.
• The override-topics argument consists of a list of colon (:) delimited key/values. This is because there is no standard way to parse map/dict like structures as command line arguments.
  • : Was picked because its not a valid character that can be used in kafka topics (see https://www.ibm.com/docs/en/integration-bus/10.0?topic=bus-producing-messages-kafka-topics). As a bonus it aesthetically looks nice.
• In addition to the typical command line configuration parameters single-message-per-kafka-request has been added. This cli flag configures the Kafka producer with a set of configuration's whos semantics allow exactly once message delivery semantics without having to use Kafka transaction API (see Support Transactional API for Restore #98).
  • It is intended that the underlying configurations of single-message-per-kafka-request can possibly change but the user can just rely on the fact that single-message-per-kafka-request provides these semantics
  • When Kafka transactional API is supported this will be under a different CLI flag (since to use the transactional API properly you also need to setup the consumer in a specific way which is outside the control of the restore app, the restore app only contains a publisher and not a consumer).
  • I am open to using a different name than single-message-per-kafka-request as long as it doesn't contain transactional so its not confused with the official Kafka transactional API.
• RestoreClientInterface/RestoreClient was adjusted to accommodate a KillSwitch. Unlike Backup which gives a Control (that is gotten from the Alpakka Kafka consumer), the Alpakka producer has no such mechanism so we use a standard akka-stream killswitch which will gracefully terminate the entire stream.
• The cli Main waits forever when calling restore.run() with Await.result(app.run(), Duration.Inf). I did it initially this way because restore's can take significant amounts of time (theoretically even days?) and so I didn't want to add an upper bound on how long it takes because in doing so you kind of defeat the point of having an upper bound anyways.

[mdedetrich]

This change is necessary because otherwise the restore CLI fails with

[WARN ] ManifestInfo - You are using version 10.2.7 of Akka HTTP, but it appears you (perhaps indirectly) also depend on older versions of related artifacts. You can solve this by adding an explicit dependency on version 10.2.7 of the [akka-http-spray-json] artifacts to your project. Here's a complete collection of detected artifacts: (10.1.11, [akka-http-spray-json]), (10.2.7, [akka-http, akka-http-core, akka-http-testkit, akka-http-xml, akka-parsing]). See also: https://doc.akka.io/docs/akka/current/common/binary-compatibility-rules.html#mixed-versioning-is-not-allowed

Note that this is the exact same as the backup equivalent at https://github.com/aiven/guardian-for-apache-kafka/blob/main/build.sbt#L166-L173 which had the same problem.

[mdedetrich]

These settings are also the same as the backup CLI at https://github.com/aiven/guardian-for-apache-kafka/blob/main/build.sbt#L175-L185