To make them a bit more flexible. Can now do things like this:

  server:start([{'Product-Name', "Bob"}]),
  server:listen({tcp, [{capx_timeout, 2000}]})

Beware that the latter is completely different from this:

  server:listen(tcp, [{capx_timeout, 2000}])

Since there's no reason to reject a client that wants to establish
multiple connections, given that diameter can handle it.

So as to do what's now recommended in diameter(1), in the grandparent
commit.

Which hasn't received any attention for some time. Clean it up, rename
the poorly named peer.erl (it's Diameter *nodes* that are implemented),
and make the it possible to specify arbitrary transport configuration.

The timer was renamed in commit abea7186.

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.

In particular, remove the unnecessary list-or-record answer.

As it should. The previous discard (surely) pre-dated being able to
return {answer_message, 3001} from a handle_request callback.

The output could make it impossible to use the shell. Counters returned
diameter:service_info/2 can be used to check for expected happenings.