Refactor live-repair start and send

[mkeeter]

Downstairs::begin_repair_for had confusing semantics: it was used to both start live-repair (setting self.repair to Some(..)) and to send subsequent jobs. Most of its arguments were only used in one or the other case.

This PR splits it into three functions:

• start_live_repair initializes self.repair and sends the first live-repair IO
• send_next_live_repair sends the next live-repair IO
• Under the hood, both of these functions call send_live_repair_jobs to reserve repair IDs and actually send IO

In passing, I also removed the extent_count argument from notify_live_repair_progress, since it can be computed locally (basically just pushing the change from #1672 further down the call stack).

[leftwo]

If we send this first repair with min_id not set, is it possible this could be
a problem with dependency removal?

The path for the first repair goes like this:
send_live_repair_jobs()
-> create_and_enqueue_..()
-> self.enqueue()
-> self.send()
In send, we prune_deps(), where we check min_id.

I think it's going to be okay, but .. I want to be sure (as this was a problem with the initial LR and min_id was added to prevent a hang).

• A non LiveRepair downstairs should not prune deps, as it must honor them.
• A downstairs under Repair, this is the first actual repair it is getting, so any previous IO should have been skipped already, and should not be on the dependency list?

At least, thats what I think will happen. Does that make sense? Even if true, I still feel like we are relying on some behavior that may not be obvious.

[mkeeter]

I agree that it should work as written, because there should be no IO going to a downstairs that's LiveRepairReady. However, I realized it's an easy fix to initialize min_id to self.peek_next_id(), so let's just do that instead to remove all doubt!

Fixed in 50e16fd