Drain grouptaskqueue of the gtask before detaching it.

[shurd]

Summary

taskqgroup_detach() would remove the task even if it was
running or enqueued, which could lead to panics (see D17404). With
this change, taskqgroup_detach() drains the task and sets a new flag
which prevents the task from being scheduled again.

I've added grouptask_block() and grouptask_unblock() to allow control
over the flag from other locations as well.

Test Plan

Test with e1000 devices, and have Intel test with the initial
panicing testcase

[dhw]

I tested this, as my laptop had panicked after updating from r339583 to r339639. I first updated sources to r339681, then applied the patch (via 'svn patch'); did the normal update, rebooted, and the em0 NIC worked just fine -- certainly no panic.

For reference:
FreeBSD 13.0-CURRENT #148 r339681M/339681: Wed Oct 24 05:48:37 PDT 2018 root@localhost:/common/S4/obj/usr/src/amd64.amd64/sys/CANARY amd64 1300000

[krzysztof.galazka_intel.com]

@shurd Thanks! That makes more sense than my version. I can't reproduce the ixl panic on my machine but Iets wait for an official verification by Jeff's team.

@dhw Thank you for testing the patch!

[shurd]

Add gtaskqueue_drain_locked() to hold common code for gtaskqueue_drain()
and grouptask_block().

[shurd]

Add missing semi-colon.

[dhw]

Given the changes, this morning, I:

• Reverted the previous changes to sys/kern/subr_gtaskqueue.c and sys/sys/gtaskqueue.h
• Updated sources from r339681to r339706
• Applied the new diff (again, via 'svn patch')
• Performed a normal source-based update

No panics or other issues; em0 NIC works.

[jeffrey.e.pieper_intel.com]

We cannot reproduce the panic that was resolved with https://reviews.freebsd.org/D17404, so it looks okay to me.