Let generic AVPs be encoded/decoded in alternate dictionaries

To support specifications like RFC 7683 DOIC, that only define AVPs, not
applications. AVPs that aren't known to the application dictionary in
question could previously not be decoded. Configuring alternate
dictionaries with the new transport/service option avp_dictionaries
changes this, so that AVPs like DOIC's Grouped OC-OLR can presented in
their fully decoded glory. Encode is also extended, allowing things like
the following to be encoded in an outgoing message:

  'AVP' => [{'OC-OLR', #{'OC-Sequence-Number' => 1,
                         'OC-Report-Type' => 0,
                         'OC-Reduction-Percentage' => [25]}}]

A diameter_gen_doic_rfc7683 dictionary is installed, but
avp_dictionaries isn't specific to DOIC.

This commit also solves the problem demonstrated a few commits back,
that application AVPs aren't decoded in answers setting the E-bit. Test
coverage will come in a subsequent commit.

1 files changed, 1 insertions, 0 deletions

diff --git a/lib/diameter/src/base/diameter.erl b/lib/diameter/src/base/diameter.erl
index 69ef6f4ec0..b90b794611 100644
--- a/lib/diameter/src/base/diameter.erl
+++ b/lib/diameter/src/base/diameter.erl
@@ -356,6 +356,7 @@ call(SvcName, App, Message) ->
     | {capx_timeout, 'Unsigned32'()}
     | {strict_capx, boolean()}
     | {strict_mbit, boolean()}
+    | {avp_dictionaries, [module()]}
     | {disconnect_cb, eval()}
     | {dpr_timeout, 'Unsigned32'()}
     | {dpa_timeout, 'Unsigned32'()}