There were a number of issues with RABBITMQ_PLUGINS_EXPAND_DIR:

- It was undocumented in the context of the generic unix package, and
  if unwisely set could do an effective "rm -rf" in an unintended
  location.

- It did not take account of the possibility that multiple nodes could
  be starting at once, and so doing plugins activation
  simultanteously.

Instead, use RABBITMQ_MNESIA_DIR/plugins-scratch.  This avoids the
need to extend the generic unix package documentation, the location is
node-specific, and the distinctive plugins-scratch subdirectory
reduces the risk of unintended file deletions.
(transplanted from 064b8797493bb290156fb72a54f9e9276df0faed)

This does in fact not alter the behaviour at all due to the following:

- if the alarm is active the alarm registration will call the handler
straight way, which will send a {conserve_memory, true} message to the
reader.
- the reply to the alarm registration is sent after that, and from the
same process - the alarm process - so by the time the reader loops
around the mainloop again the {conserve_memory, true} message is
guaranteed to be in the mailbox
- on looping around, the reader request a frame_header from the
socket. The reader has already sent connection.open_ok to the client,
and the client may have started sending commands straight away. But
all the reader is going to see of that to start with is an {inet_async,
...} message for a frame_header. That is guaranteed to end up in the
mailbox after the {conserve_memory, true} message.

Thus the reader is guaranteed to process the {conserve_memory, true}
message before handling any more data from the socket.

With this change it is rather more obvious that the memory alarm
status gets taken into account before any more client data is
processed.