base: fix faults in rm_session de-constructor path

First make the clients inaccessible and dissolve them from the entrypoint. If
this isn't the first step the clients may be obtained again between
the unlock and lock steps in the destructor.

Additionally the clients may be removed in between the unlock and call
sequence, which renders such client pointers dangling and causes spurious page
faults. Keep instead a lock as long as possible and when it is required to
release a lock, then the pointer to the objects must be revalidated.

Replace the dissolve function with a remove_client implementation as suggested
by #13, which avoids that the cpu_session may call dissolve with a dangling
pointer of a already removed rm_client object. Instead the pager must be
released explicitly.

Related to issue #549
Related to issue #394
Related to issue #13
base: add remove_client to rm_session

Fixes #13
codezero: fix compiler warnings int/unsigned

Warnings like the following:

warning: narrowing conversion of ‘((Genode::Platform_pd*)this)->Genode::Platform_pd::_space_id’ from ‘int’ to ‘Codezero::l4id_t {aka unsigned int}’ inside { } is ill-formed in C++11 [-Wnarrowing]
nova: increase number of available cap indexes

Noux test requires some more indexes. We don't free all up because of a missing
reference counting implementation of indexes in base-nova.

Issue #394
nova: use kernel branch adjusted to Genode

Since we have now more than a handful patches to the vanilla kernel, we
better switch to a separate git repository in order to review and to maintain
the patches more effectively.

Remove the patches, they are already in the kernel branch.

Fixes #394
base: fix dangling session pointers in rm_session

If page faults are handled concurrently (as for base-nova) the traverse lookup
call in rm_session_component must be thread safe, which it isn't.
If the faulting area is backed by nested dataspaces which are managed by
various rm_sessions then a race happens under following circumstances
(triggered occasionally by the bomb test).

The traverse lookup may return a pointer to a rm_session of a nested dataspace.
If the rm_session is in parallel subject to destruction it happened that faults
got enqueued to the faulters list of the deleted rm_session and internally to
a list of the current rm_session of the Rm_client.

During destruction of the faulting Rm_client the associated rm_session will
be dissolved from the Rm_client, which leads to dereferencing the
dangling pointer of the already destructed rm_session.

On base-nova the memory of the rm_session object get unmapped eventually, so
that the de-referencing of the dangling pointer caused page faults in core.

The memory on other kernels inside core never get unmapped so that the
bug doesn't trigger visible faults.

The patch replace the keeping of a rm_session pointer by keeping a
capability instead. The rm_session object must be looked up now explicitly in
the Object_pool implementation, which implements proper reference counting on
the rm_session object.

Issue #549
nova: fix cleanup handling in server object

As first step the rpc object must be freed up so that the kernel object
(portal) vanishes. Then the object must be removed from the internal object
pool list so that the object can't be obtained anymore. And then the cleanup
call can be performed (_leave_server_object) since now all names to the
rpc_object are gone.

Doing it in different order (as before the commit) there is a very very little
chance (but the bomb test triggers it occasionally) that the rpc_object can be
obtained again by an incoming IPC - even it is already scheduled for removal.

Fixes partly #549
nova: fix pager cleanup handling

The cleanup call must be performed already during the _dissolve function
shortly after the object at the cap_session is freed up. Otherwise there
is the chance that an in-flight IPC will find the to be dissolved function
again.

Bomb test triggered the case, that a already dissolved rpc_object was found
by a in-flight IPC. If the rpc_object was already freed up by alloc->destroy
the thread using this stale rpc_object pointer cause page-faults in core.

Fixes partly #549
base: fix deadlock in core_env on base-nova

During a ram_session->free call in 'core' the lock in core_env.h is taken.
Then in the ram_session::_free_ds implementation the dissolve function for the
dataspace is called. base-nova tries to make sure that the ds is not
accessible anymore by any kind of parallel incoming IPC by performing a
cleanup IPC. Unfortunately the dataspace_session implementation uses the very
same allocator in 'core' and may require to obtain the same lock as taken in
ram_session->free. This leads to a spurious deadlock on base-nova.

The actual free_ds implementation is mostly thread safe, since all used objects
inside there are already locked. The only missing piece is the _payload
variable. By changing the _payload variable in a atomic fashion there is no
need to lock the whole ram_session->free call which avoids deadlocks on
base-nova.

Fixes #549
core: always release Irq_proxy startup lock

Prior this patch the startup lock was not released if the call of
'_associate()' failed. In this condition, the caller of the constructor
was infinitely blocked.
libc_lwip: use libc's 'get-/freeaddrinfo()'

This patch reduces problems when connecting Arora to lighttpd via
nic_bridge. Patch by Christian Prochaska
core: support upgrades of init's Env:: sessions
base: fix sporadic context thread area faults

reverts 68156918ee5ee8150f11f5403439582dda0b9bb3
"base: apply thread.cc fix of foc to base"

Depending on the context area a fixed location is calculated where the
memory for the stack is attached to. If the context area is released before the
detach call, the very same context area can be reused and memory for the new
stack is attached for a new thread. The detach of the old thread would then
revoke the mapping for the new thread which will cause a un-handled page fault.

Issue #549
nova: kill thread with no pager where recall fails

Issue #549
nova: fix lock guard usage in cap selector

Issue #549
base: reset _last_applicant variable

Fixes #647
core_mem.diff
Lock test

Related to #646.
base-linux: use the 'futex' syscall for blocking

With this patch, the 'futex' syscall gets used for blocking and unblocking
of threads in the 'Lock' implementation.

Related to #646.
lock_check.diff