cluster: avoid throwing on duplicate recovery

[andrwng]

This adds a conservative check for in-progress recoveries at bootstrap time: if a recovery is in progress, we will log an error message instead of throwing.

In practice we don't expect this error code to be hit, but in case of a bug or somesuch, this seems preferable over throwing and blocking applying controller messages.

Note that update_in_progress is the only error code to come out of cluster_recovery_table::apply().

Backports Required

• none - not a bug fix
• none - this is a backport
• none - issue does not exist in previous branches
• none - papercut/not impactful enough to backport
• v23.3.x
• v23.2.x

Release Notes

• none

[vbotbuildovich]

ducktape was retried in https://buildkite.com/redpanda/redpanda/builds/47255#018ea1a9-3797-4822-927e-c1aa2ec64eff

ducktape was retried in https://buildkite.com/redpanda/redpanda/builds/47255#018ea1a9-379c-4a16-a377-cc66aefd4cb9

[andrwng]

Thanks for the review!

[vbotbuildovich]

/backport v23.3.x

[vbotbuildovich]

Failed to create a backport PR to v23.3.x branch. I tried:

git remote add upstream https://github.com/redpanda-data/redpanda.git
git fetch --all
git checkout -b backport-pr-17563-v23.3.x-853 remotes/upstream/v23.3.x
git cherry-pick -x 14663a988851ad3d8e547469d11d33bab47a6d5f

Workflow run logs.

[dotnwat]

@andrwng why backport? wasn't this all a clang-tidy cleanup patch to begin with?

[andrwng]

@andrwng why backport? wasn't this all a clang-tidy cleanup patch to begin with?

Ah I thought the cleanup patch was being backported so I followed suit. Will close the backport since looks like that backport has also been closed

[dotnwat]

ahh, right on. yeh seems like maybe it won't be backported as there were some conflicts or something.