Spawn molds instead of promoting workers

[casperisfine]

The big benefit is we no longer reduce capacity when a promotion is happening.

The downside is that complexity is a bit increased.

Another important change is that since we fork, the various Process._fork callbacks will be invoked. For some it will be a positive (e.g. dropped connections), for others it may be somewhat negative (e.g. restarted background threads).

This was suggested by @matthewd.

[paarthmadan]

Cool, neat idea

[paarthmadan]

Suggested change

	Once the `mold` is done loading, the `master` ask it to spawn the desired number of workers:
	Once the `mold` is done loading, the `master` asks it to spawn the desired number of workers:

[paarthmadan]

Looks like you're missing the ``` backticks to start the codeblock

[paarthmadan]

It's possible I've misunderstood the intent, but this test doesn't explicitly reap any molds, it seems to assert that when a new mold is spawned, the @mold replaces the old with the new.

Should we change the name of the test or perhaps add something like:

diff --git a/test/unit/test_children.rb b/test/unit/test_children.rb
index b0313bc2..34808f67 100644
--- a/test/unit/test_children.rb
+++ b/test/unit/test_children.rb
@@ -78,6 +78,11 @@ def test_reap_old_molds
       assert_equal 42, second_mold.pid
 
       assert_equal [first_mold, second_mold], @children.molds
+
+      @children.reap(24)
+
+      assert_equal [second_mold], @children.molds
+      assert_equal second_mold, @children.mold
     end
 
     def test_reap_pending_mold

[casperisfine]

Thanks @paarthmadan, all good points.