Default IDENTIFY timeout is 5000ms which is too short for enterprise disks

[AlanCui4080 <me@alancui.cc>]

Hi,

I have two ST4000NM000A-2HZ100 on my computer which is of seagate enterprise 
line.  But when i recovery from suspend, the kernel complains about that and 
the zpool kicks the disk off:

```
ata2: found unknown device (class 0)
ata4: found unknown device (class 0)
ata2: found unknown device (class 0)
ata2: SATA link up 6.0 Gbps (SStatus 133 SControl 300)
ata4: found unknown device (class 0)
ata4: SATA link up 6.0 Gbps (SStatus 133 SControl 300)
ata4.00: qc timeout after 5000 msecs (cmd 0xec)
ata4.00: qc timeout after 5000 msecs (cmd 0xec)
ata4.00: failed to IDENTIFY (I/O error, err_mask=0x4)
ata4.00: revalidation failed (errno=-5)
ata2.00: qc timeout after 5000 msecs (cmd 0xec)
ata2.00: failed to IDENTIFY (I/O error, err_mask=0x4)
ata2.00: revalidation failed (errno=-5)
ata2: SATA link up 6.0 Gbps (SStatus 133 SControl 300)
ata4: SATA link up 6.0 Gbps (SStatus 133 SControl 300)
ata2.00: configured for UDMA/133
ata4.00: configured for UDMA/133
```
I think that's cause by the too slow spinup for my disk.
After make libata to wait longer, the warning disappeared.

```
# cat /proc/cmdline
libata.ata_probe_timeout=10
```

```
ata2: SATA link up 6.0 Gbps (SStatus 133 SControl 300)
sd 1:0:0:0: [sda] Starting disk
ata2.00: configured for UDMA/133
ata4: SATA link up 6.0 Gbps (SStatus 133 SControl 300)
sd 3:0:0:0: [sdb] Starting disk
ata4.00: configured for UDMA/133
```


Meanwhile, the seachest reports that the startup time from standby is 9sec, 
which is longer that the default ATA IDENTIFY timeout.

```
/dev/sg0 - ST4000NM000A-2HZ100 - **** - TN04 - ATA

Standby Z : Recovery Time : 90 (in 100msecs)
```

```
static const unsigned int ata_eh_identify_timeouts[] = {
         5000,  /* covers > 99% of successes and not too boring on failures */
        10000,  /* combined time till here is enough even for media access */
        30000,  /* for true idiots */
        UINT_MAX,
};
```

I tested the hard drive, and as long as it's never set to STANDBY_Z (disk 
stops spinning, requiring 9 seconds to recover) and kept in IDLE_C (platter 
slows down, requiring 3.2 seconds to recover), this error never occurs.

It's been seen many users complaining about this elsewhere, should we quirk 
for those "heavy" disk? Or print some warnings about how to relax this 
problem.

Alan