Use a BoundedVec in ValidationResult (#6603)

* Use a `BoundedVec` in `ValidationResult`

> Use a `BoundedVec` for `upward_messages` and `horizontal_messages` in order to
> limit the number of individual messages/memory allocations right at decoding
> time. The reason for this is that the `ValidationResult` may contain a code
> upgrade (including a full PVF binary), so the total size limit can't be set
> too low and this limit will still allow several millions of upward messages,
> which will (due to the memory allocator overhead) already have a
> non-negligible memory footprint in decoded form.

* List all fields when hashing so we don't miss one

* Define types for  `BoundedVec`s of messages

* Fix test compile errors

* Depend on `bounded-collections` 0.1.4 (fixes allocation issue)

* Fix compilation issue

* Derive `Hash` instead of manual `impl`

* Avoid use of unwrap

polkadot/parachain/test-parachains/undying/src/wasm_validation.rs

@@ -37,8 +37,10 @@ pub extern "C" fn validate_block(params: *const u8, len: usize) -> u64 {
 	parachain::write_result(&ValidationResult {
 		head_data: GenericHeadData(new_head.encode()),
 		new_validation_code: None,
-		upward_messages: sp_std::vec::Vec::new(),
-		horizontal_messages: sp_std::vec::Vec::new(),
+		upward_messages: sp_std::vec::Vec::new().try_into().expect("empty vec fits within bounds"),
+		horizontal_messages: sp_std::vec::Vec::new()
+			.try_into()
+			.expect("empty vec fits within bounds"),
 		processed_downward_messages: 0,
 		hrmp_watermark: params.relay_parent_number,
 	})