zfs: Fix spa import procedure for multi-vdev pools

This patch is fixing a bug when using a ZFS pool with more than
a single vdev, i.e. blk device. In other words, it will allow
us to use a ZFS pool with multiple devices, and even add more
devices to an existent pool on-the-fly.

The root:
OSv-specific spa_import_rootpool and spa_generate_rootconf functions
are limited to a single vdev, therefore spa_root_vdev, a structure
keeping root vdev information, would not be aware of additional vdevs
available in the underlying pool.

The problem happens when vdev_mirror_map_alloc asks spa_root_vdev
for these additional vdevs.
It does so by using the function vdev_lookup_top that is intended to
return the requested vdev from spa_root_vdev, however, it will return
NULL when spa_root_vdev isn't aware of the requested vdev.
Consequently, a NULL dereference will always happen, when using a pool
with more than one vdev.

Example:
page fault outside application, addr: 0x0000000000000000
[backtrace]
...
0x00000000002f599b <vdev_config_sync+2427>
...

After investigation, I discovered that spa_import_rootpool and
spa_generate_rootconf should be fixed to generate proper information
about all the vdevs associated with the pool being imported.

Solution was to use FreeBSD-specific procedures for importing the root
pool, then all the vdev children information will be properly added into
the SPA namespace, and pools with more than a single vdev will start
working as expected.

Signed-off-by: Raphael S. Carvalho <raphaelsc@cloudius-systems.com>
zfs: ioctl(TRYIMPORT) must fail if config buf is insufficient

ZFS maintains pool configuration in nvlist inside VDEV label. Block
devices which are part of a pool are called as VDEVs. VDEVs form a
hierarchical tree like structure. A VDEV label contains information
describing this physical VDEV as well as all VDEVs which share common
top level logical VDEV.

When pool is imported, ZFS finds appropriate block device and reads
VDEV label for pool configuration. Since a single VDEV only maintains
information about all VDEVs which share common logical VDEV. It has to
refresh the configuration information to know about other logical VDEVs.

ZFS uses IOCTL(ZFS_IOC_POOL_TRYIMPORT) to try a pool import. The
TRYIMPORT also returns, to caller, complete pool configuration along
with it's health information. However, if the passed buffer from
userland is insufficient to capture all config information, it must
fail with ENOMEM. Instructing the caller, to pass larger buffer. The
expected size of the buffer is also passed to caller. The caller,
refresh_config() then allocates larger buffer and retries ioctl.

Signed-off-by: Prasad Joshi <prasadjoshi.linux@gmail.com>