Warn if repairs overlap on tables using different settings

[jdonenine]

Currently, Reaper will prevent any creation of repair runs/schedules that would involve overlapping tables but different settings (number of segments, full or incremental, different tables list,...).

We want to slightly loosen this position and trade it for a warning that would require the user to acknowledge the repair goes against best practices/recommendations before getting it to start.

Post 4.0, we want users to be aware that another schedule/run is using another mode (incremental/full) than the one configured, but won't prevent it as the bugs related to incremental are fixed in this version.

The wording of the warning should accomodate both pre and post 4.0 cases.

In terms of code changes, it involves:

• Adding a force setting to the REST operations for adding a repair run or a repair schedule
• Make those operations fail with a specific status code to make it clear the error can be enforced along with the proper warning message
• in the UI, handle the error code so that it displays a pop up box which allows to re-run the request with the force setting to true

Recreation of original #1008

┆Issue is synchronized with this Jira Task by Unito
┆Epic: Incremental Repair
┆Fix Versions: reaper-2.3.0,k8ssandra-1.4.0
┆Issue Number: K8SSAND-474
┆Priority: Medium

[jdonenine]

Comment from @michaelsembwever in the original issue:

We want to slightly loosen this position and trade it for a warning that would require the user to acknowledge the repair goes against best practices/recommendations before getting it to start.

Not just general best practices and recommendations, but if it goes against the existing repair schedule in place. Take for example the scenario where both OPs and Dev have access to Reaper, and OPs has defined the schedule correctly. When Dev logs in and to a manual repair we want to warn them that they are not honouring the settings the OPs team have defined.

The error message (both from REST responses and the pop up box in the UI) should explain how the manual repair differs from the scheduled repair. (Intuitive feedback and confirmation that the manual repair is compatible with how the tables are routinely repaired.)