Add SLO cloning functionality

[CoenWarmer]

Resolves #149917

📝 Summary

This PR adds the functionality to clone an existing SLO. It also adds some more tests for the SLO List page.

Looks like this:

Screen.Recording.2023-01-31.at.14.13.38.mov

✅ Checklist

• It should be possible to select an existing SLO from the SLO List page and select "Clone"
• After clicking "Clone" an SLO with the same configuration should appear in the list
• The name of the newly cloned SLO should be "[Copy] <<Title of existing SLO>>"

[elasticmachine]

Pinging @elastic/actionable-observability (Team: Actionable Observability)

[CoenWarmer]

I noticed React was complaining about duplicate ID's when running tests, this fixes that

[kdelemme]

Ah yes good catch I forgot to change the id for this one 🙈

[kibana-ci]

💚 Build Succeeded

• Buildkite Build
• Commit: d4e5dc3
• Storybooks Preview

Metrics [docs]

Async chunks

Total size of all lazy-loaded chunks that will be downloaded as the user navigates the app

id	before	after	diff
observability	574.1KB	574.7KB	+614.0B

History

• 💚 Build #104191 succeeded 16ae86e955d1178c78d9ea00adb800b2f56f2d87
• 💔 Build #104178 failed 475b7b5

To update your PR or re-run it, just comment with:
@elasticmachine merge upstream

[kdelemme]

LGTM!

Just a remark regarding finally block that sets success to false every time. Otherwise my other nit was addressed before I finished the review :p

[kdelemme]

I think finally is called regardless of the success or failure of the try. So in this case, we always set success to false.

[CoenWarmer]

Yeah, I was experimenting a bit with this pattern... will most likely revert

[kdelemme]

nit: passing the boolean state feels strange when reading the code, especially from the modal component: e.g. onDeleting(true) or onDeleting(false)
Maybe we can keep onDeleting() without boolean that sets the state to true, and the handleClonedOrDeleted can reset both state (deleting and cloning) to false?

[CoenWarmer]

Indeed, this was exactly what I thought as well. Tbh, this is going to change if and when we move to React Query: it will have less prop plumbing because we can just listen for the api interaction finishing inside the list component.