* anders/diameter/hardening/OTP-11721:
  Change answer_errors default from report to discard

In the same vein as commit 00584303, to avoid logging traffic-related
happenings.

Not that the value in diameter.hrl is just documentation: the value is
set explicitly when diameter:start_service/2 creates diameter_app
records.

Commit 4ce2d3a6 (diameter-1.4.2, OTP-11007) disabled the decode of
values in Failed-AVP components since any error caused the decode of
Failed-AVP itself to fail. This is less than useful since (1) we should
be able to decode it given that we've sent it (modulo mangling on the
way to the peer and back), and (2) it's not unheard of to examine
Failed-AVP to see what the peer objected to.

This commits adds a best-effort decode: decode if possible, otherwise
not, using the same abuse of the process dictionary as commit bbdb027c.

Commit 4ce2d3a6 added the insertion of a single bit into binary AVP data
to induce an encode error in the case of a header length that pointed
past the available bytes: a 5014 = DIAMETER_INVALID_AVP_LENGTH error.
Commit 838856b fixed this for stringish Diameter types, but both commits
neglected the case in which the offending AVP isn't known to the
dictionary in question. Unless the AVP was regarded as erroneous for
other reasons (eg. an M-bit resulting in 5001) it would be happily be
packed into an 'AVP' field. If it was regarded as an error, the record
could be passed back to diameter_codec:pack_avp/1, and if the record
contained header data then there was no clause to deal with the
unpleasantry.

Deal with it by having the dictionary module strip the extra bit and
flag the AVP as 5014, and by having diameter_codec handle any extra bit
coming from an dictionary compiled against an old diameter_gen. An old
dictionary won't detect 5014 however, so dictionaries should be
recompiled.

Change most of the guards in diameter_codec from is_bitstring/1 to
is_binary/1. What's being passed to the decode functions are binaries
received other the network. The only case in which a non-binary
bitstring is when we've placed an extra bit there ourselves. (Modulo
someone doing something they shouldn't.)

The former were a little over-enthusiastic and could cause a node to be
logged to death if a peer Diameter node was sufficiently ill-willed.
The function calls are to diameter_lib:log/4, the arguments of which
identify the happening in question, and which does nothing but provide a
function to trace on. Many existing log calls have been shrunk.

The only remaining traffic-related report (hopefully) is that resulting
from {answer_errors, report} config, and this has been slimmed.

* anders/diameter/17.0_release/OTP-11605:
  Fix diameter.hrl comment typos

A Diameter Header Command Code is 24 bits, not 8, and an Application-ID
is 32 bits, not 24.

Thanks to Austin Aigbe for pointing it out.

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.

An AVP setting the M-bit was not regarded as erroneous if it was defined
in the dictionary in question and its container (message or Grouped AVP)
had an 'AVP' field. It's now regarded as a 5001 error (AVP_UNSUPPORTED),
as in the case that the AVP is not defined.

The previous commit ensures that only one will be reported in an answer
message when diameter itself sets Result-Code/Failed-AVP.

The order of errors in #diameter_packet.errors is that in which they're
detected, not the reverse as previously.