[Coretime chain] Add high assignment count mitigation to testnets

[seadanda]

Fixed in Polkadot and Kusama in polkadot-fellows/runtimes#434 and this PR just adds to testnets.

We can handle a maximum of 28 assignments inside one XCM, while it's possible to have 80 (if a region is interlaced 79 times).
This can be chunked on the coretime chain side but currently the scheduler on the relay makes assumptions that means we can't send more than one chunk for a given core.

This just truncates the additional assignments until we can extend the relay to support this. This means that the first 27 assignments are taken, the final 28th is used to pad with idle to complete the mask (the relay also assumes that every schedule is complete). Any other assignments are dropped.

[seadanda]

/cmd prdoc --pr 6022 --bump patch --audience "Runtime User"
edit: this should have been --audience "runtime_user"

[bkchr]

Is the underlying problem tracked in an issue?

[seadanda]

Just made it - that was too far down on my TODO list but sorted now

[kianenigma]

Suggested change

	assignment_truncated[0].1 = 57_600u16.saturating_sub(total_parts);
	assignment_truncated[0].1 = PartsOf57600::FULL.saturating_sub(total_parts);

[seadanda]

Just realised that this is just a u16 in the broker pallet, rather than the type that the relay chain uses. This means we don't have FULL etc here. It will introduce another dependency and require an into anyway. I think longer term we should change the type in the broker pallet, but this will be a breaking change

[bkchr]

I think longer term we should change the type in the broker pallet, but this will be a breaking change

In the relay chain it is also a u16, but just a transparent wrapper around u16. While this is a "breaking change" on the code level, it is not changing the storage layout or anything. Thus, changing it can be done very easily.