msleep: make it accept any kind of mutex

First of all, I am sorry. I am sorry Avi, Dor, Pekka, God, Dennis Ritchie, et caterva.
I am so very sorry. This is probably one of the ugliest things ever written by a C
programmer in the history of programming.

The story is: ZFS defines its own mutex of type kmutex_t, which is basically just a OSv
in our implementation. In a piece of code currently commented out (not for long), it calls:

    msleep(&needfree, &arc_reclaim_thr_lock, 0, "zfs:lowmem", 0);

The problem is that our msleep implementation expects a "struct mtx" which is our own
wrapper around mutex (Maybe that should be changed? Does anybody remember why it was
done this way?)

Keep in mind that we are going to great lenghts not to change ZFS (ifdefing code out
is generally fine), so the casting solution could not be used. I've tried to change the
for-ZFS definitions of mutex in the BSD glue code, but then, after a couple of hours
I was still resolving conflicts with all the other parts that would break because they
were expecting a certain type that was now changed.

I eventually set for the current ugly but functional solution: code msleep in a
way that it can accept any kind of mutex. That is really ugly because by "any
kind of mutex" I really mean any kind of crap the user passes and good bye type
safety altogether. But it works with minimal changes, and more importantly, with
all the changes being in *our* glue code.

If anybody have other ideas, I would be happy to try them out. But at this time,
I believe that to be the best compromise.

Signed-off-by: Glauber Costa <glommer@cloudius-systems.com>
Signed-off-by: Pekka Enberg <penberg@cloudius-systems.com>
bsd glue: simplify curproc so it returns a pointer

There is (currently commented out) code in ZFS that checks things like:

    if (curproc == pageproc) {
        /* Do something really great */
    }

The problem is that with our current implementation of curproc (designed for Xen)
that will break, because we will return a pointer to a in-stack variable that is
created on-demand and only contains the pid of the process.

Returning the thread address will make those checks works, but we will be forced
to give up on accessing fields inside it altogether. If we *really* must, we can
have a structure that have the fields in the same offset as our thread class.

But our thread class is defined in a .hh file, so *good luck* calculating the
offset of a field (say, id) at compile time so we can include in this other .h
file that contains exclusively C code. Since xen is the only user of the PID test,
and our resistance to changing the xen code is quite low (if at all), I'll just go
ahead and change it: storing the address of the process itself should allow us to
do compare tests the way ZFS does and get everything working.

Signed-off-by: Glauber Costa <glommer@cloudius-systems.com>
Signed-off-by: Pekka Enberg <penberg@cloudius-systems.com>
reclaim: export address of the OSV reclaimer

ZFS will perform some checks to determine if the current calling "process"
is the reclaimer. Export the address of the reclaimer thread so that test
can work.

Signed-off-by: Glauber Costa <glommer@cloudius-systems.com>
Signed-off-by: Pekka Enberg <penberg@cloudius-systems.com>
ZFS: remove one OSv ifdef

For every OSv specific ifdef we remove in ZFS, God ressurects a kitten.

After some recent additions and fixes, that piece of code can now be
compiled out. It is the reclaimer code, so it is very welcome.

But beware: that does not means we are reclaiming yet. That only means that we
wired up the ZFS ARC reclaiming process to the BSD notification system.

We now need to somehow wire that notification system with the OSv shrinking
infrastructure. That is the easy part. And after that, of course, balance the
calls between ARC and balloon. That is the hard part.

Signed-off-by: Glauber Costa <glommer@cloudius-systems.com>
Signed-off-by: Pekka Enberg <penberg@cloudius-systems.com>