Add pre- and post-exec commands.

[Gerrit91]

This offers some advantages:

• tini is not required anymore
• we can use distroless database image like etcd:3.5.7

Closes #45.

The backup-restore-sidecar container will not contain `tini` anymore in the next minor release. Instead, execute the backup-restore-sidecar directly and use pre- and post-exec commands as introduced in this release of the backup-restore-sidecar. This approach also allows to migrate to distroless database images.

[Gerrit91]

I tried out the RethinkDB restore and forced the restore by running it manually from the CLI in the backup-restore-sidecar pod.

Before that:

{"level":"info","timestamp":"2023-08-24T13:32:02Z","logger":"rethinkdb","caller":"rethinkdb/rethinkdb.go:120","msg":"starting rethinkdb database within sidecar for restore"}                                                                     
{"level":"info","timestamp":"2023-08-24T13:32:02Z","logger":"rethinkdb","caller":"rethinkdb/rethinkdb.go:130","msg":"waiting for rethinkdb database to come up"}                                                                                  
{"level":"info","timestamp":"2023-08-24T13:32:02Z","logger":"rethinkdb","caller":"probe/probe.go:18","msg":"start probing database"}                                                                                                              
{"level":"info","timestamp":"2023-08-24T13:32:05Z","logger":"rethinkdb","caller":"rethinkdb/rethinkdb.go:150","msg":"rethinkdb in sidecar is now available, now triggering restore commands..."}                                                  
{"level":"info","timestamp":"2023-08-24T13:32:05Z","logger":"rethinkdb","caller":"utils/cmd.go:28","msg":"running command","command":"/usr/local/bin/rethinkdb-restore","args":"--connect=localhost:1 /tmp/backup-restore-sidecar/restore/files/re
thinkdb"}                                                                                                                                                                                                                                         
Error: restoring database was not successful: error running restore command: Usage: rethinkdb restore FILE [-c HOST:PORT] [--tls-cert FILENAME] [-p] [--password-file FILENAME] [--clients NUM] [--shards NUM_SHARDS] [--replicas NUM_REPLICAS] [-
-force] [-i (DB | DB.TABLE)]...                                                                                                                                                                                                                   
                                                                                                                                                                                                                                                  
rethinkdb-restore: error: Unable to connect to server: Could not connect to localhost:1, Wrong password exit status 2

So, I assume it is somehow broken already?

Here is with it:

{"level":"info","timestamp":"2023-08-24T13:42:17Z","logger":"rethinkdb","caller":"rethinkdb/rethinkdb.go:150","msg":"rethinkdb in sidecar is now available, now triggering restore commands..."}
{"level":"info","timestamp":"2023-08-24T13:42:17Z","logger":"rethinkdb","caller":"utils/cmd.go:28","msg":"running command","command":"/usr/local/bin/rethinkdb-restore","args":"--connect=localhost:1 --password-file=/rethinkdb-secret/rethinkdb-password.txt /tmp/backup-restore-sidecar/restore/files/rethinkdb"}
Error: restoring database was not successful: error running restore command: Extracting archive file...
  Done (0 seconds)
Importing from directory...
Error: import failed: The following tables already exist, run with --force to import into the existing tables:
  metalapi.asnpool
  metalapi.asnpoolinfo
  metalapi.event
  metalapi.filesystemlayout
  metalapi.image
  metalapi.integerpool
  metalapi.integerpoolinfo
  metalapi.ip
  metalapi.machine
  metalapi.migration
  metalapi.network
  metalapi.partition
  metalapi.size
  metalapi.sizeimageconstraint
  metalapi.switch
  metalapi.switchstatus exit status 1

I think, it is okay that the restore does not succeed when there is already data present. Not sure if it makes sense to add a --force flag.