Move most of shell scripts to Erlang code

A large part of the rabbitmq-server(8) and CLI scripts, both
Bourne-shell and Windows Batch versions, was moved to Erlang code and
the RabbitMQ startup procedure was reorganized to be closer to a regular
Erlang application.

A new application called `rabbitmq_prelaunch` is responsible for:

  1. Querying the environment variables to initialize important
     variables (using the new `rabbit_env` module in rabbitmq-common).
  2. Checking the compatibility with the Erlang/OTP runtime.
  3. Configuring Erlang distribution.
  5. Writing the PID file.

The application is started early (i.e. it is started before `rabbit`).

The `rabbit` application runs the second half of the prelaunch sequence
at the beginning of the application `start()` function. This second
phase is responsible for the following steps:

  1. Preparing the feature flags registry.
  2. Reading and validating the configuration.
  3. Configuring logging.
  4. Running the various cluster checks.

In addition to this prelaunch sequence, the `rabbit` application start
procedure ends with a "postlaunch" sequence which takes care of
starting enabled plugins.

Thanks to this, RabbitMQ can be started with `application:start(rabbit)`
as any other Erlang application. The only caveats are:

  * Mnesia must be stopped at the time `rabbit_prelaunch` is started,
    and must remain stopped when `rabbit` is started, to allow the
    Erlang distribution setup and cluster checks. `rabbit` takes care of
    starting Mnesia.

  * Likewise for Ra, because it relies on the `ra` application
    environment to be configured.

Transitioning from scripts to Erlang code has the following benefits:

  * RabbitMQ start behavior should be identical between Unix and
    Windows. Also, features should be on par now. For instance, RabbitMQ
    now writes a PID file on Windows, like it always did on Unix-based
    systems.

  * The difference between published packages and a development
    environment are greatly reduced. In fact, we removed all the "if
    this is a dev working copy, then ..." blocks.

    As part of that, the `rabbit` application is now treated like its
    plugins: it is packaged as an `.ez` archive and written to the
    `plugins` directory (even though it is not technically a plugin).

    Also in a development copy, the CLI is copied to the top-level
    project. So when testing a plugin for instance, the CLI to use is
    `sbin/rabbitmqctl` in the current directory, not the master copy in
    `rabbit/scripts`.

  * As a consequence of the previous two points, maintaining and testing
    on Windows is now made easy. It should even be possible to setup CI
    on Windows.

  * There are less issues with paths containing non-US-ASCII characters,
    which can happen on Windows because RabbitMQ stores its data in user
    directories by default.

This process brings at least one more benefit: we now have early logging
during this prelaunch phase, which eases diagnostics and debugging.

There are also behavior changes:

  * The new format configuration files used to be converted to an
    Erlang-term-based file by the Cuttlefish CLI. To do that,
    configuration schemas were copied to a temporary directory and the
    generated configuration file was written to RabbitMQ data directory.

    Now, Cuttlefish is used as a library: everything happens in memory.
    No schemas are copied, no generated configuration is written to
    disk.

  * The PID file is removed when the Erlang VM exits.

  * The `rabbit_config` module was trimmed significantly because most of
    the configuration handling is done in `rabbit_prelaunch_conf` now.

  * The RabbitMQ nodename does not appear on the command line, therefore
    it is missing from ps(1) and top(1) output.

  * The `rabbit:start()` function will probably behave differently in
    some ways because it defers everything to the Erlang application
    controller (instead of reimplementing it).

1 files changed, 2 insertions, 35 deletions

diff --git a/scripts/rabbitmq-defaults.bat b/scripts/rabbitmq-defaults.bat
index 18d4f46943..0da11f2a0c 100644
--- a/scripts/rabbitmq-defaults.bat
+++ b/scripts/rabbitmq-defaults.bat
@@ -1,23 +1,8 @@
 @echo off

 

-REM ### next line potentially updated in package install steps

-REM set SYS_PREFIX=

-

-REM ### next line will be updated when generating a standalone release

-REM ERL_DIR=

-set ERL_DIR=

-

-REM This boot files isn't referenced in the batch scripts

-REM set SASL_BOOT_FILE=start_sasl

+set SASL_BOOT_FILE=start_sasl

 set CLEAN_BOOT_FILE=start_clean

-

-if exist "%RABBITMQ_HOME%\erlang.mk" (

-    REM RabbitMQ is executed from its source directory. The plugins

-    REM directory and ERL_LIBS are tuned based on this.

-    set RABBITMQ_DEV_ENV=1

-)

-

-REM ## Set default values

+set BOOT_MODULE=rabbit

 

 if "!RABBITMQ_BASE!"=="" (

     set RABBITMQ_BASE=!APPDATA!\RabbitMQ

@@ -29,22 +14,4 @@ if not exist "!RABBITMQ_BASE!" (
     mkdir "!RABBITMQ_BASE!"

 )

 

-REM BOOT_MODULE="rabbit"

-REM CONFIG_FILE=${SYS_PREFIX}/etc/rabbitmq/rabbitmq

-REM LOG_BASE=${SYS_PREFIX}/var/log/rabbitmq

-REM MNESIA_BASE=${SYS_PREFIX}/var/lib/rabbitmq/mnesia

-REM ENABLED_PLUGINS_FILE=${SYS_PREFIX}/etc/rabbitmq/enabled_plugins

-set BOOT_MODULE=rabbit

-set CONFIG_FILE=!RABBITMQ_BASE!\rabbitmq

-set LOG_BASE=!RABBITMQ_BASE!\log

-set MNESIA_BASE=!RABBITMQ_BASE!\db

-set ENABLED_PLUGINS_FILE=!RABBITMQ_BASE!\enabled_plugins

-set GENERATED_CONFIG_DIR=!RABBITMQ_BASE!\config

-set ADVANCED_CONFIG_FILE=!RABBITMQ_BASE!\advanced.config

-set SCHEMA_DIR=!RABBITMQ_BASE!\schema

-

-REM PLUGINS_DIR="${RABBITMQ_HOME}/plugins"

-for /f "delims=" %%F in ("!TDP0!..\plugins") do set PLUGINS_DIR=%%~dpF%%~nF%%~xF

-

-REM CONF_ENV_FILE=${SYS_PREFIX}/etc/rabbitmq/rabbitmq-env.conf

 set CONF_ENV_FILE=!RABBITMQ_BASE!\rabbitmq-env-conf.bat