make erlang:process_info/1 not retrieve messages

process_info/1 retrieves a number of properties related to a process,
including the list of messages in its mailbox.  This is potentially
unsafe if the target process has a large number of queued messages:

- there is no a priori upper bound on the amount of memory being
  allocated to hold that list, and
- the loop to retrieve the messages is uninterruptible, so the
  Erlang scheduler where this executes blocks for the duration

We've seen process_info/1 bring down heavily loaded nodes on more
than one occasion.  At least once it appeared to have blocked the
Erlang heart process from executing, causing the external heart to
kill the VM.

Consequently this removes 'messages' from the list of process_info
tags to retrieve for process_info/1.  Note that process_info/1 still
retrieves 'message_queue_len', and process_info/2 can still retrieve
'messages' when asked to.

A few places in the OTP libraries need minor adjustments, since they
want 'message_queue_len' but compute it from the length of the list
of messages.

Take care of the call of erlang:get_stacktrace() in
module mnesia_lib.

The remaining call (in module mnesia_lib) is taken care
of in the following commit.

* maint:
  Updated OTP version
  Prepare release
  mnesia: Fix checkpoint crash

* dgud/mnesia/checkpoint-crash/OTP-14841:
  mnesia: Fix checkpoint crash

* dgud/mnesia/slow-startup/OTP-14829:
  mnesia: Read schema user properties directly

Bad timing can cause retain messages to go to a new process if
checkpoint name is reused directly and the checkpoints contain
different tables.

Ignore those messages instead of crash.

* maint:
  Updated OTP version
  Prepare release
  mnesia: Read schema user properties directly
  ssh: testcases for space trailing Hello msg
  ssh: Don't remove trailing WS in Hello msg

* maint-19:
  Updated OTP version
  Prepare release
  mnesia: Read schema user properties directly
  ssh: testcases for space trailing Hello msg
  ssh: Don't remove trailing WS in Hello msg