Add support for new relx directive that provides start/stop script hooks

[lrascao]

New 'extended_start_script_hooks' directive that allows the developer to define six different hook scripts to be invoked at pre/post start/stop/install upgrade phases.
Besides these custom defined scripts other types of builtin scripts are also available, these offer pre-packaged functionality that can be used directly, they are:

• pid - writes the beam pid to a configurable file location
  (/var/run/<rel_name>.pid by default).
• wait_for_vm_start - waits for the vm to start (ie. when it can be pinged)
• wait_for_process - waits for a configurable name to appear in the erlang process registry
  The hook scripts are invoked with the 'source' command, therefore they have access to all the variables in the start script.
  These hook scripts apply only to start, stop and upgrade/downgrade/install/uninstall commands.
  The paths are relative to the start script, and the syntax is:

                  {extended_start_script_hooks, [
                        {pre_start, [{custom, "hooks/pre_start"}]},
                        {post_start, [{pid, "/tmp/foo.pid"},
                                      {wait_for_process, some_process},
                                      {custom, "hooks/post_start"}]},
                        {pre_stop, [{custom, "hooks/pre_stop"}]},
                        {post_stop, [{custom, "hooks/post_stop"}]}
                    ]},

Possible use cases:

• Cuttlefish integration, generate sys.config on the fly when starting the release
• Generate a pid to a custom location
• Feedback provider, when starting the node a post_start script can check that the entire application-specific boot process has succeeded

[tsloughter]

Oh hm, this is great! I need to try this out and use it for my new cuttlefish provider. I'll hopefully merge it in today.

[tsloughter]

@lrascao problem with this patch is the start hooks only run before start and not foreground or console, right? Would need to also run before those.

[lrascao]

right, i'll update the PR

[lrascao]

@tsloughter have you had a chance to try this out with cuttlefish?

[tsloughter]

I haven't since your last update.

[bitwalker]

One problem with this (and affects all of these) is that the post_start event will either never be executed, or will only be executed when the release stops, which is obviously not desired for a post_start event handler. I think the best way to do this is by backgrounding the task, executing the post_start task, then waiting on the PID, instead of blocking on exec. I'm using this approach right now in some work I'm doing in Mix, because I wanted to trap exit signals and cleanly shut down the VM.

[lrascao]

sounds good, so something like:

   pre_start_hook
   Pid = spawn (exec "$@" -- ${1+$ARGS})
   post_start_hook
   wait on Pid

did i understood correctly?

[lrascao]

i've since updated the PR, it now sends the execs to background and waits on them after the post hook

[lrascao]

@tsloughter this is ready for review
@GoelDeepak @saleyn any feedback from you guys would also be great

[tsloughter]

Looks great! Should we wait for +1's from @GoelDeepak and @saleyn ?

[lrascao]

yeah, let's wait a few days, they might have some improvement suggestions

[saleyn]

Yes, looks like a good idea.

[lrascao]

@tsloughter i guess it's good to merge