https://bugs.launchpad.net/tarantool/+bug/1160789

When multiple sessions get disconnected at the same
time, the same fiber is running all disconnect triggers.
This fiber's sid was  not changed between trigger invocations,
and on_disconnect() triggrer of the next disconnected
session would see not its own session id in box.session.id(),
but the previous session's session id.

The fix is to correctly set box.session.id() before handling
any iproto request.
In on_connect() request, sid is 0, but soon it is
reset in session_create().

No test case since the bug requires that there is a full
libev queue, so that multiple on_disconnect() triggers
fire in the same loop.

libreadline already goes with libhistory compiled in,
no reason to add it to the dynamically linked library
list.
Apparently, explicitly listing libhistory leads to
the dl loader pre-loading it instead of the compiled-in
version, which, in turn, leads to a crash on the first
history search in the command line client.

The fix is to remove cmake dependency on libhistory
as well as on libncurses, which we don't need either
(always require libtermcap).

A session trigger would always use the same coroutine, for both connect and
disconnect, as well as for multiple sessions.

If a trigger runs insert() or update(), anything that yields the current
coro, the coro stack would get corrupted for the next parallel invocation.

Use an own coroutine for each invocation of a session trigger.

Preserve the zero-warnings patch.

When server wrapper script failed to start
the server, it used to try to send a email
to somebody about this. This has never been
tested, nor used.

At least make sure it works when it does try
to do it.

twistd by default starts with umask 077.
This is why buildbot has umask setting.

rpm by default takes file and directory umask
from the build directory.

When building tarantool rpm under buildbot,
twistd default umask was inherited. Thus
all paths were created in rwx-- mode.

Now add to this cmake bug CMake bug 0012864.
That is, by default, cmake cpack generator
adds %dir directive for every intermediate
dir into the spec.

E.g. if there is a destination file /etc/rc.d/foo,
the spec gets
%dir /etc
%dir /etc/rc.d

Together with the default dir access mask of
twistd this nicely messed up our rpm install: an
install of Tarantool 1.4.8-59 rpm for CentOS would change
/etc and /usr access mode to 700.

Two things are done about that: Tarantool no longer
uses a cpack generated cpeck file. Extraneous %dir
directives are removed from the spec file. This
should minimize the damage of a broken twistd config,
should it happen again.

All buildslaves are reconfigured and restarted with umask 022.

A just-connected session would get stuck not reading input
if only a part of request was received.

Conflicts:
	test/box/lua.result
	test/box/lua.test

- auto_increment key start from '1' now

Conflicts:

	test/big/tarantool.cfg

(A tip from Alexey Kapitansky).

Correctly convert lsn to ulonglong, correctly
evaluate --from and --to range.

https://bugs.launchpad.net/tarantool/+bug/1119389

https://bugs.launchpad.net/tarantool/+bug/1131108

https://bugs.launchpad.net/tarantool/+bug/1124304

https://bugs.launchpad.net/tarantool/+bug/1130663/

Preparation for addition of 't' format specifier in
pack/unpack: move these functions to box_lua.m.

There were two cases when the new async I/O worked incorrectly.
The problems only revealed themselves under specific
concurrency circumstances.

In one case, the client would get a mix of pieces of different
packets (responses).

The reason for this was that, when selecting which output buffer
to write to the client, the flushing algorithm used to select
whichever of two buffers, associated with a session, had data to
flush.
This worked OK as long as the entire contents of the buffer could
be written in one writev() call. But when writev() would only be
able to write a part of the buffer, the next writev() could
already be done with another buffer, thus producing a mix of
*partial* writes from both buffers.

Between two buffers used for a session, one is always newer than
the other (contains responses to requests which came in earlier).
So basically the bug was that we would select a newer
buffer for flushing, while there were still unhandled requests
in the older buffer.

One approach to a fix would be to, once started, keep writing
the newer buffer until there is nothing to write in it.

The actual fix chooses a simpler approach: to never begin
with a newer buffer, until the older one is completely written.
Thus, there is never reordering of output between two
output buffers, only within a single buffer.

The second bug was caused by wrong calculation of write offset
for iproto header. When iproto_header would fall on the
border of two iov vectors, obuf_book would rightfully
discard the tail of the first iov vector, and "position"
the header at the beginning of the second vector.
However, the savepoint used to memcpy() the output would
still point at the first vector, and the header would be
(partially) written at the end of the first vector,
not at the beginning of of the second.
This led to a) write beyond allocated memory b) loss
of a piece of a packet (effect seen by the client).

The fix is to correctly record the write position when
making a booking. obuf_book signature is changed
respectively.

No test cases since the bug is only spottable under certain
concurrency circumstances (a single CPU box, client/server I/O).
@todo: add unit tests.

Conflicts:

	test/box/lua.result