dhcp: fix parsing of DHCP options

There are several issues with current code. Firstly, the LENGTH_OK
macro was used in the condition in while(). This macro was checking if
options + op_len does not exceed packet limit. This macro works fine
when used from PARSE_OP() inside the switch, but because 'options' is
bumped up by op_len at the end of the loop body, use of this macro in
the while condition may result in premature exit of the loop. This was
causing that some times OSv was not parsing network mask and gateway
leaving them at 0.0.0.0 when started on Goodle Compute Engine. As a
result OSv was not responding over network. See issue #254.

Another issue was that the stop condition which checks for op ==
DHCP_OPTION_END was using 'op' from the outer context, which was never
overwritten. The actual variable which was changed based on the packet
content was redeclared inside the loop.

A third problem, spotted by Vlad, is that the code was not handling
DHCP_OPTION_PAD properly. This option has only opcode byte and no
following length byte. Currrent code would attempt to read the length
byte and skip by that amount, which would yiled incorrect parsing
result.

Reviewed-by: Vlad Zolotarov <vladz@cloudius-systems.com>
Signed-off-by: Tomasz Grabiec <tgrabiec@cloudius-systems.com>
Signed-off-by: Pekka Enberg <penberg@cloudius-systems.com>
zfs: spa_zio_taskq[ZIO_TYPE_FREE][ZIO_TASKQ_ISSUE]->tq_lock contention

Reviewed by: Matthew Ahrens <mahrens@delphix.com>
Reviewed by: George Wilson <george.wilson@delphix.com>
Reviewed by: Christopher Siden <christopher.siden@delphix.com>
Reviewed by: Gordon Ross <gordon.ross@nexenta.com>
Approved by: Richard Lowe <richlowe@richlowe.net>

Reference: https://illumos.org/issues/3581

Patch taken from Illumos and slight changes were needed to port it to OSv.

This patch targets improvement on taskq lock contention by dispatching work
over independent task queues. ZFS on Linux devops mention that it's not clear
whether or not this issue affects their port, but profile results showed that
time spent on taskq_thread() was reduced by about 11%.
Apart from getting performance benefits, the number of threads in OSv was
nicely reduced (from ~344 threads to ~224; so possibly saving a good amount
of memory footprint).
Also good for stepping towards our synchronicity with ZFS upstream.

Addressing the issue #247.

Reviewed-by: Glauber Costa <glommer@cloudius-systems.com>
Signed-off-by: Raphael S. Carvalho <raphaelsc@cloudius-systems.com>
Signed-off-by: Pekka Enberg <penberg@cloudius-systems.com>