Fix definition of ssize_t and off_t.

During diskless replication the master forks a child, which on posix
simply inherits the socket file descriptors for the connections to
the slaves.
A unix pipe is also used for the child to report the results back
to the master.

The bulk of the porting work is in making sure that the socket
file descriptors and pipe file descriptor are propagated correctly
from the master to its child.

Refactor BeginForkOperation in preparation for diskless replication:
- Separate copying of operation data and child process creation
- Provide specific entry points for each operation type

1. Server unxtime may remain not updated while loading AOF, so ETA is
not updated correctly.

2. Number of processed byte was not initialized.

3. Possible division by zero condition (likely cause of issue #1932).

Slave processes were not using the master process log file.
On Unix this is relying on the server.logfile variable being available
to the slave processes through fork(), and reopening the logfile
in the slaves (on every log event).
On Windows we don't use server.logfile and require an explicity call
to setLogFile.
I resorted to explicitly passing the logfile to the slaves as a
command line argument, so the logfile argument (and logging) can be
available to the slave before qfork and globals setup have completed.

Writing to the same file atomically from multiple processes requires
using CreateFile with FILE_APPEND_DATA, instead of fopen, which provides
atomicity on Unix but not on Windows.

Also changed the implementation to not reopen the logfile on every
log event, and not flushing the file on every write. Performance is
dramaticaly improved this way.

Child now reports full info to the parent including IDs of slaves in
failure state and exit code.

We need to avoid that a child -> slaves transfer can continue forever.
We use the same timeout used as global replication timeout, which is
documented to also affect I/O operations during bulk transfers.

While the socket is set in blocking mode, we still can get short writes
writing to a socket.

To perform a socket write() for each RDB rio API write call was
extremely unefficient, so now rio has minimal buffering capabilities.
Writes are accumulated into a buffer and only when a given limit is
reacehd are actually wrote to the N slaves FDs.

Trivia: rio lacked support for buffering since our targets were:

1) Memory buffers.
2) C standard I/O.

Both were buffered already.

We need to remember what is the saving strategy of the current RDB child
process, since the configuration may be modified at runtime via CONFIG
SET and still we'll need to understand, when the child exists, what to
do and for what goal the process was initiated: to create an RDB file
on disk or to write stuff directly to slave's sockets.

error != success; and 0 != number of bytes written

Closes #1806

Closes #857

dictAdd returns DICT_OK, not REDIS_OK. They both
have the same underlying values, so it works even though
the code is technically wrong.

Fixes #1512

Also quit ASAP when we are still loading a DB, since care is not needed
in this special condition, especially for a SIGINT.

When we are blocked and a few events a processed from time to time, it
is smarter to call the event handler a few times in order to handle the
accept, read, write, close cycle of a client in a single pass, otherwise
there is too much latency added for clients to receive a reply while the
server is busy in some way (for example during the DB loading).

(Note: commit message modified by @antirez for clarity).

fdapi not properly mapping fstat in config.c, so we ended up invoking CRT version without the rfd->fd translation resulting in the CRT calling exit(). Fixes issue 43.

fox for issue #90. info.rdb_changes_since_last_save not being properly updated. Also dealt with the exit code from a failed fork not making it back to the parent.

Previously, the (!fp) would only catch lack of free space
under OS X.  Linux waits to discover it can't write until
it actually writes contents to disk.

(fwrite() returns success even if the underlying file
has no free space to write into.  All the errors
only show up at flush/sync/close time.)

Fixes antirez/redis#1604

server.unixtime and server.mstime are cached less precise timestamps
that we use every time we don't need an accurate time representation and
a syscall would be too slow for the number of calls we require.

Such an example is the initialization and update process of the last
interaction time with the client, that is used for timeouts.

However rdbLoad() can take some time to load the DB, but at the same
time it did not updated the time during DB loading. This resulted in the
bug described in issue #1535, where in the replication process the slave
loads the DB, creates the redisClient representation of its master, but
the timestamp is so old that the master, under certain conditions, is
sensed as already "timed out".

Thanks to @yoav-steinberg and Redis Labs Inc for the bug report and
analysis.

Added dictionary master hash to global state being copied into qforked process. This fixes the fork/expire problems.

replacing win32_cow implementation with win32_qfork. replication currently broken, but all other unit tests are working.

The previous fix for false positive timeout detected by master was not
complete. There is another blocking stage while loading data for the
first synchronization with the master, that is, flushing away the
current data from the DB memory.

This commit uses the newly introduced dict.c callback in order to make
some incremental work (to send "\n" heartbeats to the master) while
flushing the old data from memory.

It is hard to write a regression test for this issue unfortunately. More
support for debugging in the Redis core would be needed in terms of
functionalities to simulate a slow DB loading / deletion.

Starting with Redis 2.8 masters are able to detect timed out slaves,
while before 2.8 only slaves were able to detect a timed out master.

Now that timeout detection is bi-directional the following problem
happens as described "in the field" by issue #1449:

1) Master and slave setup with big dataset.
2) Slave performs the first synchronization, or a full sync
   after a failed partial resync.
3) Master sends the RDB payload to the slave.
4) Slave loads this payload.
5) Master detects the slave as timed out since does not receive back the
   REPLCONF ACK acknowledges.

Here the problem is that the master has no way to know how much the
slave will take to load the RDB file in memory. The obvious solution is
to use a greater replication timeout setting, but this is a shame since
for the 0.1% of operation time we are forced to use a timeout that is
not what is suited for 99.9% of operation time.

This commit tries to fix this problem with a solution that is a bit of
an hack, but that modifies little of the replication internals, in order
to be back ported to 2.8 safely.

During the RDB loading time, we send the master newlines to avoid
being sensed as timed out. This is the same that the master already does
while saving the RDB file to still signal its presence to the slave.

The single newline is used because:

1) It can't desync the protocol, as it is only transmitted all or
nothing.
2) It can be safely sent while we don't have a client structure for the
master or in similar situations just with write(2).