reseed OpenSSL PRNG upon fork() of workers

reseed OpenSSL PRNG upon fork() of workers

OpenSSL seeds its PRNG with the process ID, so if a process ID
is recycled, there's a chance of indepedent workers getting
repeated PRNG sequences over a long time period iff the same
PID is used.

This only affects deployments that meet both of the following
conditions:

1) OpenSSL::Random.random_bytes is called before forking
2) worker (but not master) processes are die unexpectedly

The SecureRandom module in Ruby (and Rails) uses the OpenSSL
PRNG if available.  SecureRandom is used by Rails and called
when the application is loaded, so most Rails apps with
frequently dying worker processes are affected.

Of course dying worker processes are bad and entirely the
fault of bad application/library code, not the fault of
Unicorn.

Thanks for Alexander Dymo for reporting this.

ref: http://redmine.ruby-lang.org/issues/4579