Be lenient with the M-bit in Grouped AVPs

RFC 6733 says this, in 4.4:

  Receivers of a Grouped AVP that does not have the 'M' (mandatory) bit
  set and one or more of the encapsulated AVPs within the group has the
  'M' (mandatory) bit set MAY simply be ignored if the Grouped AVP itself
  is unrecognized. The rule applies even if the encapsulated AVP with its
  'M' (mandatory) bit set is further encapsulated within other sub-groups,
  i.e., other Grouped AVPs embedded within the Grouped AVP.

The first sentence is mangled but take it to mean this:

  An unrecognized AVP of type Grouped that does not set the 'M' bit MAY
  be ignored even if one of its encapsulated AVPs sets the 'M' bit.

This is a bit of a non-statement since if the AVP is unrecognized then
its type is unknown. We therefore don't know that its data bytes contain
encapsulated AVPs, so can't but ignore any of those that set the M-bit.
Doing anything else when the type *is* known would be inconsistent.

OTP-11087 (commit 066544fa) caused the M-bit on any unrecognized AVP to
be regarded as an error, unrecognized being taken to mean "not
explicitly defined as a member of its container". (That is, an AVP that
can't be packed into a dedicated record field, which is slightly
stronger than "not defined".) This fixed the original intention for
top-level AVPs but broke the required leniency for Grouped AVPs whose
type is known. This commit restores the leniency.

Note that dictionary files need to be recompiled for the commit to have
effect.

Thanks to Rory McKeown for reporting the problem.

0 files changed, 0 insertions, 0 deletions