Also add comments to identify the corresponding OTP releases. Purposely don't use regexp version numbers to be explicit about previously released versions. (Could use them in one direction but then app suite needs to be adapted.)
RFC 3588 allowed only 3xxx result codes in an answer-message (that is,
an answer that sets the E-bit) while RFC 6733 also allows 5xxx result
codes. Setting request_errors = answer tells diameter to answer 5xxx
errors itself. Returning {answer_message, integer()} from a
handle_request callback allows both 3xxx and 5xxx result codes to be
set. {protocol_error, integer()} is retained for 3xxx result codes.
In particular, don't put an error tuple in the errors field of
a #diameter_packet{} when Result-Code and the E-bit are in conflict, put
{integer(), #diameter_avp{}}.
When receiving a request for which errors have been detected during decode, diameter previously used the errors list in the decoded diameter_packet record to unconditionally set Result-Code and Failed-AVP in the outgoing answer. It wasn't particularly delicate in doing so however and would happily set a 5xxx Result-Code even if a handle_request callback returned an answer-message, leading to an encode error. This behaviour became even less endearing as of commit ac452e28, which made it possible to handle_request to take place even for protocol errors. (ie. When a callback typically should return an answer-message.) This commit fixes the behaviour by only setting a value that's appropriate for the answer in question, either a 3xxx or a 5xxx, depending on if the answer's an answer-message or not. It also allows handle_request to prevent diameter from setting anything by setting errors = false in a returned diameter_packet. Ideally it should have been errors = [] but the empty list is the default value for the errors field and changing the default (ideally there shouldn't have been one) would require recompilation of all modules including diameter.hrl: choose the less attractive 'false' to avoid such backwards incompatibility. The request reception is also refactored somewhat to shorten some call chains.
Configuring the value 'callback' all errors detected in incoming requests to result in a handle_request callback. The default value 'answer_3xxx' is the previous behaviour in which diameter answers protocol errors without a callback.
The value determines whether or not an unexpected message length in the header of an incoming messages causes the peer process to exit, the message to be discarded or handled as usual. The latter may only be appropriate for message-oriented transport (eg. SCTP) since stream-oriented transport (eg. TCP) may not be able to recover the message boundary once a length error has occurred.
Traffic handling is connected to the service implementation through the pick_peer callback and failover but diameter_service was getting unwieldy as home to both the service process and traffic handling.
In particular, remove fields containing values that are known (as of the preceding commit) to the request process.