When entire contents of the output buffer is flushed, we must reset
write start and end positions. If the buffer can be recyced, they
both are reset to point to the beginning of the buffer, otherwise write start
is advanced to match write end.

The old code would always execute *begin = *end assignment, regardless
of whether it's case 1) (full reset) or 2) (advancing write start).

gcc 4.8 could reorder this assignment, and put it in front of conditional
iobuf_reset(). In that case, write start could point beyond write end,
since iobuf_reset() resets write end to zero.

A funny bug which would hit only under heavy load, only if there are
-O2 optimizations, and no debug prints.

Fixes gh-849 'Compile error on CentOS'

Expliclitly prohibit Gcc versions which do not support lambdas.

Do stuff in box_free() only if initialization has succeeded.

Extract index_find() logic into space.h

- upsert semantics is update or insert, not "always update"
- upsert doesn't return tuple
- bind upsert as tuple method in Lua (useful for QA)
- ensure upsert is properly encoded in xlog

Implement 'strict' module, which prohibits use of undeclared global
variables.

require('strict').on() turns strict mode on
require('strict').off turns strict mode off

Turn strict on by default in debug build, off in release builds.

Don't subtract con->parse_size on every call to iproto_connection_close(),
there may be many calls if there are many outstanding requests when
the socket is closed.

Conflicts:
	src/box/iproto.cc

Conflicts:
	src/box/lua/call.cc
	src/box/tuple_update.cc

There is still a valid case for fork() after start, it's box.coredump().

The assert that replaced recovery_atfork() call would sporadically fail
even in our own test suite.

Revert the change.

Any function of Lua log module would first evaluate the call stack,
and only then invoke the logger function -- even if the text is
then sent to /dev/null because log level is too low.

Short cut the log call in case the log level is low and the message
is muted.

Check ev_async_pending() rather than state of the pipe to find
out whether we need a syscall. On a simple read-only test pipe->pipe
is empty while there is already a pending event more than a few times a
millisecond.

At the same time, checking ev_async_pending() is more expensive, since
it's an atomic variable, but overall performance increased
after the patch, so the cost seems to be justified.

Use staged mutex lock/unlock, cool off the WAL mutex

Since we no longer fork to make a snapshot, we don't need
an atfork() handler in box. We still need atfork() handler
in the app server to handle background=true option.

See also gh-517

refactoring: extract wal writer, rename replication.[hc] -> relay.[hc]
Extract the write ahead log into its own C file, rename
replication.[hc] to relay.[hc]
Cleanup headers.
No semantical code chagnes.
wal: begin changes necessary to switch to the common bus