TRIM/UNMAP/DISCARD support for vdevs

This adds TRIM (a.k.a UNMAP, DISCARD, hole punching) support for vdevs. The original patch is from Pawel Jakub Dawidek (pjd@FreeBSD.org) who wrote it for FreeBSD. I'm just porting it to ZFS On Linux. Original discussion is in #598. Note that you need zfsonlinux/spl#168 to build this.

Clean branch (caution: history may be rewritten): https://github.com/dechamps/zfs/compare/trim-clean

This code is largely untested (especially the Linux-specific parts) and carries a *high risk of data corruption* since it deals with deletion of data. **DO NOT APPLY THIS PATCH IF YOU CARE ABOUT YOUR DATA. USE AT YOUR OWN RISK. EXPECT DATA LOSS.**

@behlendorf: I'm not asking you to merge this. At least not right now. I'm just opening a pull request to give the patch more visibility and get more testing. As usual, as soon as it's ready and received enough testing for your taste, I'll clean it and open another, final pull request.

- [FreeBSD thread][freebsd]
- [Illumos thread][illumos]

## Features ##

- Automatic, fully transparent TRIM on data, slog and cache vdevs. TRIM requests are not immediately issued in order not to break pool disaster discovery, and are batched for optimal performance.
- Whole vdev TRIM on zpool create/add/attach (similar to what mke2fs does).
- Whole vdev TRIM on cache vdevs on export/remove/destroy.
- Supports disk vdevs using the standard Linux DISCARD interface (which translates to ATA TRIM, SCSI UNMAP, or any other method supported by the vdev block device driver)
- Supports file vdevs using the Linux file hole punching interfaces.

## Current status ##

- ztest was OK, but was broken by some of the latest optimizations.
- `zconfig.sh` passes with flying colors starting from dccbfafe02d0c12f70c3e402fd481e0345d58365.
- `zfault.sh` passes with flying colors starting from dccbfafe02d0c12f70c3e402fd481e0345d58365.
- This patch is feature-complete since 4c1f8e17843d8b5e05474575ab7d8a0984b19af3. The only work that remains is testing/bug hunting.

## Usage instructions ##

Note that the new feature is disabled by default (`zfs_notrim=1`). To use it, you have to explicitly load the module with `zfs_notrim=0`. For TRIM to work, you need to have vdevs that support it, e.g. SSDs. If you don't have any, you can still test using a Linux RAM block device (`rd` module), as it supports discards. Note that if you choose to test with `rd`, make sure to use `ashift=12`, else you will trigger [a corruption bug in rd][1].

There is a module parameter (`trim_txg_limit`) that specifies after how many TXGs the freed data is actually discarded on the device (default 32). Indeed, the algorithm doesn't discard data immediately so that pool disaster recovery (i.e. `zpool -F`) don't break. I suggest you test with the default and with a low value (e.g. 1) to make the algorithm more aggressive, which might trigger different bugs.

There is a module parameter (`trim_txg_batch`) that specifies how many TXGs are squashed together in order to batch (merge) TRIM requests (default 32). The optimal value heavily depends on your workload and the performance characteristics of your physical vdevs.

Module parameters `trim_l2arc_limit` and `trim_l2arc_batch` work the same way but are specific to cache devices. They are expressed in seconds instead of TXGs.

There is a module parameter (`zfs_trim_zero`) that, when enabled, makes sure TRIMmed data is zeroed. Note that for disk vdevs, this effectively means that TRIM is disabled and replaced by "write zeroes". This mode allows ztest to test TRIM even on filesystems that don't support file hole punching. Outside ztest, it can also be used to diagnose corruption issues more reliably. Note that, for obvious reasons, performance greatly suffers in this mode.

The patch introduces a new kstat page in `/proc/spl/kstat/zfs/zio_trim`. It allows you to quickly check if TRIM is actually working or not. Keep in mind that if you're using a high `trim_txg_limit` (e.g. 64), then it may take a while before TRIM requests are actually issued.

## TRIM support on file vdevs (a.k.a file hole punching) ##

There are a few prerequisites for *file* (not disk) vdev support using Linux file hole punching capabilities:
- The underlying filesystem (where the file vdevs are stored) must support file hole punching. Currently, only OCFS2, XFS and ext4 support it. tmpfs supports it via the `truncate_range` interface, so it should work (albeit only from kernel space). Ironically, ZFS itself doesn't (yet).
- Of course, `zfs_notrim` still needs to be set to `0`, no matter what the vdev type is.
- In the case of ZFS in userspace (e.g. `ztest`), be sure that your installed Linux headers (i.e. `/usr/include/linux`) are up to date (>= 2.6.38). Also, as mentioned above, if you're using `ztest`, be sure to run it on a filesystem that supports file hole punching (tmpfs doesn't). Note that you can't change parameters using `ztest`, so you'll have to hack `trim_map.c` to manually set `zfs_notrim=0` by default and rebuild.

A good way to be sure that TRIM support on file vdev works is to do something like this with `zfs_notrim=0` and `trim_txg_limit=1`, assuming `/store` is stored on ext4 or another filesystem with file hole punching support:

    # dd if=/dev/zero of=/store/pool bs=1 count=1 seek=1024M
    # zpool create punchhole /store/pool
    # du -h /store/pool
    1.2M	/store/pool
    # dd if=/dev/urandom of=/punchhole/foo bs=1M count=100
    # du -h /store/pool
    102M	/mnt/file
    # rm /punchhole/foo
    # du -h /store/pool
    1.7M	/store/pool

Again, this section only applies to *file* vdevs, not disk (block device) vdevs. Most users have no use for TRIM support on file vdevs.

## TODO list ##
- Extensive testing for stability and data integrity

Note that I have no idea if I'll have enough time to see this whole thing through, so if you want to take care of some items of the TODO list, be my guest.

  [1]: https://bugzilla.kernel.org/show_bug.cgi?id=47711
  [freebsd]: http://lists.freebsd.org/pipermail/freebsd-current/2012-September/036777.html
  [illumos]: http://www.listbox.com/member/archive/182191/2012/09/sort/time_rev/page/1/entry/2:96/20120923191210:18E22D6A-05D4-11E2-8CE8-908B9596E3B6/