provisioner: prioritize backing votes for disputes

[ordian]

See #6249 for the context.

With our slashing design centered around backers for both valid and invalid cases and in the light of #6249, we should always prioritize missing backing votes when selecting votes for a dispute set.

• Add a test in provisioner that we if there are missing backing votes on-chain, we always select them.

[eskimor]

@BradleyOlson64 This should be fairly simple as well.

[eskimor]

Not only prioritize, but make sure there are always imported - even if the chain already knows about some valid votes for those validators.

[BradleyOlson64]

The first issue I'm seeing is that we import votes to the provisioner from the disputes subsystem in an order that can't account for backing votes specifically. It only knows about which disputes to prioritize, not which votes to prioritize.

I think a solution might be to set up another call similar to request_votes called request_backing_votes. Not sure how easy it would be to support such a call from the dispute subsystem side, but without it I don't see how we could guarantee all unknown backing votes get into the dispute set.

[ordian]

Heads up: in #6249 I implemented the following logic

// We allow backing statements to be imported after
// explicit "for" vote, but not the other way around.

This makes it easier to implement slashing with our currrent design and should be fine considering

/// Backers should not participate in explicit voting so this only possible on malicious backers.

That means if we select a backing vote (if it's not present on chain already), we should not select an explicit "Valid" vote in the same set from the same validator.

It only knows about which disputes to prioritize, not which votes to prioritize.

My understanding is vote selection in provisioner (in the new version) happens in

polkadot/node/core/provisioner/src/disputes/prioritized_selection/mod.rs

Line 168 in b4b3fa5

async fn vote_selection<Sender>(