illumos gate

During acceptance testing of #4986, this pattern was discovered:

1. 1. Create a filesystem.
2. 2. Set a refquota.
3. 3. Snapshot the filesystem.
4. 4. Send a replication stream to a new filesystem.
5. 5. On the original filesystem, fill it up to its quota.
6. 6. Snapshot the original filesystem again.
7. 7. Send an incremental stream to the same new filesystem.

What happens is that there's an overage on quota enforcement, limited by the size of a transaction. The idea was that ALL of the quota bytes would be available, even if it went over.

This is fine, until receipt of a replication stream occurs.

In the case of a change to an existing dataset, like above, there's a straightforward fix involving the reality checks around the final clone_swap paths in dsl_dataset.c.

In the case of a test like this, however:

1. 1. Create a filesystem.
2. 2. Set a refquota.
3. 3. On the original filesystem, fill it up to its quota.
4. 4. Snapshot the original filesystem.
5. 5. Send a full replication stream to a new filesystem.

The send will happen, BUT the refquota property will not be received.