EC layouts today require k >= p. This is not a Cauchy/ISA-L limit,
it comes from storing parity as RAID0|PARITY, where the p
parity objects of a raidset are concatenated along the file offset.
The parity component then needs
stripeset_count * raidset_count * p * stripe_size of
extent, which no longer fits a finite PFL extent once p > k (for
example --ec 2+3 -E 2M).

Lifting the restriction is useful for small components that should
survive a 2-OST failure. The first component of a PFL file is only a
few stripes but covers most files, and --ec 1+2 (LU-20568) or
--ec 2+3 are exactly the layouts a k >= p rule forbids.

As suggested in LU-20568, this can be handled by giving the parity
component its own layout pattern rather than reusing RAID-0. Storing
parity as LOV_PATTERN_PARITY makes the component RAID-10 shaped:
the raidsets of one stripe set are striped like RAID-0, one
stripe_size each, while inside a raidset the p parity stripes
share a single file offset like RAID-1. The parity component then
always fits the extent of the data component, for any k and p.

Unlike RAID-1 the parity stripes are not replicas, so the client must
not fan a write out to all of them: resync and verify address one
parity stripe at a time, while punch and truncate still apply to every
parity object.

EC has not shipped, so the old RAID0|PARITY encoding does not need
to be kept. The p <= k checks in lfs and llapi can be
dropped, with k+p <= 256 and p <= 15 remaining.