The added make target is described in HOWTO/TESTING.md.

For the parent commit as a diameter 2.2 patch.

Commit d9d918b2 added a gen_server whose purpose is to keep track of
visible nodes on which diameter_dist:attach/1 has been called to
register a node as a handler of incoming Diameter requests when
diameter_dist:route_session/2 is configured as spawn_opt MFA. The server
contacts visible nodes at init in order to request information, but
instead of monitoring visible to also be able to request information at
nodeup, it monitored on all nodes, resulting in gen_server casts even to
hidden nodes.

Monitor only on visible nodes since a hidden node may not be able to
deal with the new message.

* anders/diameter/21.3/OTP-15654:
  Update appup for diameter 2.2 in OTP 21.3

* anders/diameter/distribution/OTP-15398:
  Add diameter_dist_SUITE to exercise diameter_dist:route_session/2
  Add consistent hashing to diameter_dist:route_session/2
  Add options to diameter_dist:route_session/2 node selection
  Add diameter_dist for ready spawn_opt callbacks
  Tweak/document request handler callback
  Document acknowledgements in transport interface
  Fix comment typo

Spread a server over three nodes, one of which terminates a peer
connection, the other two to handle requests. Terminate transport on one
of the server nodes and ensure that answers come only from the other
two.

If the Session-Id optional value to node() mapping fails then hash
Session-Id to a node by default, instead of selecting the local node as
in the parent commit. The previous behaviour is configurable by setting
default = local in an options map.

Nodes make themselves part of the pool from which nodes are selected by
calling diameter_dist:attach/1 with the list of service names they are
willing to handle requests for, the local node being selected in the
absence of any attached nodes. The original idea was to base the node
pool on share_peers and/or use_shared_peers configuration, but that
configuration determines where outgoing requests can be sent, while
route_session/2 deals with incoming requests, so it's not obvious that
conflating the two is a good thing. (Also because
share_peers/use_shared_peers can be used in different ways; the former
could have been skipped entirely.)

The hashing effectively places nodes on a circle, a hashed Session-Id
being mapped to the nearest predecessor node (clockwise). Nodes are
rehashed with each Session-Id (with the id as salt) for a more even
distribution, at the cost of performance, although how high the cost or
how even the distribution has yet to be tested. Obviously, the larger
the number of attached nodes, the higher the cost. Adding/removing an
attached node only affects session ids that hash in the interval between
the added/removed node and its successor (hence consistent hashing).

Options are tweaked slightly compared to the parent commit, and it is
now possible to restrict the optional value mapping to specific Diameter
identities, to avoid mapping an id that was generated at the peer when
the peer is also implemented with the diameter application.

Note that diameter_dist is not yet an officially documented interface,
so could change. Documentation is in the module itself.