Explicitly Handling ProvisionableData Cases (#6757)

* Initial pass

* fmt

* Lock changes

* Implementers guide edit

* Reasoning changes

* typo

Co-authored-by: Marcin S. <marcin@bytedude.com>

* Revert "Lock changes"

This reverts commit 3131a5245c6349743789270e6d1ad7842dc4c9df.

* Getting rid of cargo.lock changes

* Argumentation update

* fmt

---------

Co-authored-by: Marcin S. <marcin@bytedude.com>

polkadot/node/core/provisioner/src/lib.rs

@@ -324,7 +324,26 @@ fn note_provisionable_data(
 				.with_para_id(backed_candidate.descriptor().para_id);
 			per_relay_parent.backed_candidates.push(backed_candidate)
 		},
-		_ => {},
+		// We choose not to punish these forms of misbehavior for the time being.
+		// Risks from misbehavior are sufficiently mitigated at the protocol level
+		// via reputation changes. Punitive actions here may become desirable
+		// enough to dedicate time to in the future.
+		ProvisionableData::MisbehaviorReport(_, _, _) => {},
+		// We wait and do nothing here, preferring to initiate a dispute after the
+		// parablock candidate is included for the following reasons:
+		//
+		// 1. A dispute for a candidate triggered at any point before the candidate
+		// has been made available, including the backing stage, can't be
+		// guaranteed to conclude. Non-concluding disputes are unacceptable.
+		// 2. Candidates which haven't been made available don't pose a security
+		// risk as they can not be included, approved, or finalized.
+		//
+		// Currently we rely on approval checkers to trigger disputes for bad
+		// parablocks once they are included. But we can do slightly better by
+		// allowing disagreeing backers to record their disagreement and initiate a
+		// dispute once the parablock in question has been included. This potential
+		// change is tracked by: https://github.com/paritytech/polkadot/issues/3232
+		ProvisionableData::Dispute(_, _) => {},
 	}
 }