OTP-12845

* bruce/change-license:
  fix errors caused by changed line numbers
  Change license text to APLv2

* anders/diameter/18/OTP-12588:
  vsn -> 1.10
  Remove dead upgrade-related code
  Update appup for 18
  Fix release note typo
  Fix comment typo

* anders/diameter/sctp/OTP-12768:
  Fix connection timeouts in test transports
  Fix start order of alternate transports
  Log discarded answers
  Ensure accepting processes are first in, first out
  Remove upgrade-related code
  Be less parallel in traffic suite
  Increase send/receive buffers for testsuite SCTP listeners
  Decrease unnecessarily long testsuite timetraps
  Simplify accepting transport start
  Simplify peeloff signaling
  Simplify socket close at terminate
  Don't monitor listener after peeloff
  Don't receive initial messages out of order
  Remove assumption that SCTP association ids will be unique

* anders/diameter/grouped_errors/OTP-12721:
  Fix decode of Grouped AVPs containing errors
  Simplify logic
  Simplify logic

A transport configured with diameter:add_transport/2 can be passed
multiple transport_module/transport_config tuples in order to specify
alternate configuration, modules being attempted in order until one
succeeds. This is primarily for the connecting case, to allow a
transport to be configured to first attempt connection over SCTP, and
then TCP in case SCTP fails, with configuration like that documented:

  {transport_module, diameter_sctp},
  {transport_config, [...], 5000},
  {transport_module, diameter_tcp},
  {transport_config, [...]}

If the options are the same in both cases, another possibility would be
configuration like this, which attaches the same transport_config to
both modules:

  {transport_module, diameter_sctp},
  {transport_module, diameter_tcp},
  {transport_config, [...], 5000},

However, in this case the start order was reversed relative to the
documented order: first tcp, then sctp. This commit restores the
intended order.

OTP-12851

Not needed with the parent commit's restart_application.

To diameter_lib:log/4, which was last motivated in commit 39acfdb0.

A listener process in diameter_sctp starts accepting transport processes
as required, either as associations are established or as diameter asks
for a processes to be started. Since this can happen in any order, the
listener maintains two queues: one for processes that diameter has
requested and which are waiting to be given an association, another for
processes that have been started to become owners of an association but
are waiting for diameter to request them. Only one queue at a time is
non-empty. The first queue's length is bounded by the number of
accepting processes configured as pool_size. Entries in the second queue
are short-lived since diameter starts a replacement transport process
whenever an existing one dies or communicates that it has an
association.

The two queues were previously implemented in an ets ordered_set, whose
keys were the pid() of transport processes. Removing an element from the
queue was then done with ets:first/1. The problem with this it's not
really a queue: there's no guarantee that pid-ordering is the same as
the order in which processes are started. If it isn't then it's possible
that an established association never be given to diameter as a
transport process if there's always a newer association whose pid sorts
first. This isn't a problem in practice since it would require new
associations to be established faster than diameter starts transport
processes, but redo the implementation as a queue, with strict FIFO
semantics.

The changes in some of the previous commits assume application restart.

Don't pass an association id that's no longer used.