Don't excise DTLs from unreadable vdev

An offline or unreadable vdev may trip the following assertion
during a resilver scan in ztest:

ztest: ../../module/zfs/vdev.c:1746: Assertion
`scn->scn_phys.scn_min_txg <= vdev_dtl_min(vd) (0x4e3 <= 0x3)' failed.
child died with signal 6

The following analysis is by George Wilson:

 The current scan is only resilvering a few txgs [70f, 711] but yet
 this vdev has a min txg of  3. The problem is that this vdev is
 currently not readable and as a result when the scan that was doing
 the resilver it actually finished but didn't copy any of the data to
 this device.

 Now a second scan comes through and the device is still offline (ie.
 not readable) so once again this device was did not have any data
 copied over to it. This time when we check if we should excise the
 DTLs from this device we determine we should since the scan is for a
 txg much higher than the max value in this device's dtl range but we
 end up tripping over this assertion:

        /*
         * When a resilver is initiated the scan will assign the
         * scn_max_txg
         * value to the highest txg value that exists in all DTLs. If
         * this
         * device's max DTL is not part of this scan (i.e. it is not in
         * the range (scn_min_txg, scn_max_txg] then it is not eligible
         * for excision.
         */
        if (vdev_dtl_max(vd) <= scn->scn_phys.scn_max_txg) {
                ASSERT3U(scn->scn_phys.scn_min_txg, <=, vdev_dtl_min(vd));

 If the device is not readable than we don't want to ever excise any
 of its dtls so we should return B_FALSE and not even bother with
 anything further.

References: https://www.illumos.org/issues/4890

Issue #2302

Signed-off-by: Ned Bass <bass6@llnl.gov>