Remove KeyBindingContainer.SendRepeats

[peppy]

Reasoning mentioned in #4773.

See a pretty shocking oversight in db22119 which went unnoticed until now as tests were focused on the non-event-based repeat handling (which is removed in this PR). Existing tests cover the fail case - revert the commit to confirm.

Breaking Changes

KeyBindingContainer.SendRepeats no longer exists

Use the KeyBindingPressEvent provided in OnPressed delegates to identify (and ignore or handle) repeats instead.

[peppy]

Blocking temporarily. A couple of oversights I'm working on still.

[peppy]

Turns out that key repeat (via event flow) wasn't really handled correctly in KeyBindingContainer until now. I've restructured things to work roughly as expected.

The existing test coverage seems to be enough to cover this behaviour.

[bdach]

I've fired off a nitpick commit to correct a slightly strange test step name.

In general this diff looks sane to me. One thing I'm not sure of, is that when SimultaneousBindingMode is not None, repeats are maybe a touch counterintuitive in that when I press and hold Ctrl+A in the key bindings grid test scene, the initial press activates A, Ctrl, and Ctrl_A actions, but then repeats only get fired for whichever single key was pressed last, which is maybe a little counter-intuitive. But I'm not really super sure what the behaviour should be there either, so maybe best to leave the simple case working as-is and tackle that edge case if it ever comes up...

[peppy]

Yeah, it isn't a 1:1 with expectations but I'd rather address that as a follow up, I think. Keep in mind it's working with the last action, not bindings, so in a simple case where Ctrl-A is bound to an action that will still get correctly repeated.

On macOS (and windows from my recollection), the last non-modifier is the key to be repeated, but modifiers are not included in the equation. So the true behaviour if we're looking for parity would be for the modifier Ctrl-A to repeat even in your scenario. We can make this happen if/when the requirement comes up.

[smoogipoo]

This should have a few more conditions, as per

osu-framework/osu.Framework/Input/KeyEventManager.cs

Lines 25 to 26 in 05920eb

	// Only drawables that can still handle input should handle the repeat
	var drawables = ButtonDownInputQueue.Intersect(InputQueue).Where(t => t.IsAlive && t.IsPresent);

But I understand that's a bit complex to get done in this PR, so looks fine as it is.

[peppy]

I saw that. But those conditionals also weren't applied to the other path as far as I can see (I guess it's less important because it's an immediate firing?) so I didn't think too much of it.

[smoogipoo]

The other path being what? In both cases it's the non-repeat path, and the expectation is that it doesn't contain !IsAlive and !IsPresent items in the first place.

[peppy]

Yeah, that part. I'll add the conditionals in a follow-up PR.

[smoogipoo]

Actually, this is just incorrect because the input queues are per-keybinding...

[peppy]

Which case would be incorrect? The idea is that the repeat is only sent to the last pressed key binding, where this queue is taken from directly.

[smoogipoo]

Right, I see. Seems okay on a second think...

[smoogipoo]

Going to need osu!-side fixes for this as well, fwiw.

[peppy]

Yeah. I did a quick testing pass and nothing was too broken (and the places this intends to fix were fixed), but there's going to be multiple places we need to block repeats. Will look at that today.