if_clone: Allow maxunit to be zero

[zlei]

Summary

Some drivers, e.g. if_enc(4), only allow one instance to be created, but
the KPI ifc_attach_cloner() treat zero as not limited, aka IF_MAXUNIT .

Introduce a new flag IFC_F_LIMITUNIT to indicate that the provided
maxunit is limited and should be respected.

Consumers are advised to use the new flag if there is an intended limit. The
usage will be easier to grep.

The behavior keep unchanged for old KPI if_clone_simple() and
if_clone_advanced().

MFC after: 1 week

[glebius]

Shouldn't that be done to if_clone_addreq_v2, too?

sys/net/if_clone.c

533–539

Do we really need the old behavior at all? There are no consumers in tree that initialize maxunit.
So could be:

maxunit = (req->flags & IFC_F_LIMITUNIT) ? req->maxunit : IF_MAXUNIT;

[zlei]

Added asserting on the compatibility of layout of struct if_clone_addreq and struct if_clone_addreq_v2 .

[zlei]

In D45757#1043796, @glebius wrote:

Shouldn't that be done to if_clone_addreq_v2, too?

The layout of struct if_clone_addreq_v2 is compatible with that of struct if_clone_addreq . i.e., maxunit of if_clone_addreq_v2 is the same with if_clone_addreq . I added a compile assert to reveal that.

[zlei]

sys/net/if_clone.c

533–539

Do we really need the old behavior at all? There are no consumers in tree that initialize maxunit.
So could be:

maxunit = (req->flags & IFC_F_LIMITUNIT) ? req->maxunit : IF_MAXUNIT;

That is exactly same with my first revision. Well later I decided to MFC this change and I worried 3rd party drivers may have already used the new KPI so I restored the old behavior.

IMO the breakage should be trivial to fix. But it seems neither RELNOTES nor UPDATING is the right place to warn developers. Any suggestions ?