Remove crp_etype and return errors directly from crypto_invoke()

ok patrick@

Retire asynchronous crypto API as it is no longer required by any driver and
adds unnecessary complexity. Dedicated crypto offloading devices are not common
anymore. Modern CPU crypto acceleration works synchronously, eliminating the need
for callbacks.

Replace all occurrences of crypto_dispatch() with crypto_invoke(), which is
blocking and only returns after the operation has completed or an error occured.
Invoke callback functions directly from the consumer (e.g. IPsec, softraid)
instead of relying on the crypto driver to call crypto_done().

ok bluhm@ mvs@ patrick@

The function crypto_dispatch() never returns an error. Make it
void and remove error handling in the callers.
OK patrick@ mvs@

Refactor softraid crypto code to allow use of a discipline-specific data
structure for RAID1C volumes, as requested by jsing@ during review of my
initial RAID1C patch.

This should effectively be a cosmetic change. The point of this exercise
is to allow the data structure changes made here in softraidvar.h.

Tested on CRYPTO and RAID1C by Josh Grosse, Matthias Schmidt, and myself.
ok jsing@

change discipline name from "RAID1C" to "RAID 1C" to match the man pages

Add a RAID1C (raid1 + crypto) softraid(8) discipline.

The RAID1C discipline encrypts data like the CRYPTO discipline, and accepts
multiple chunks during creation and assembly like the RAID1 discipline.

To deal with failing disks a RAID1C volume may be assembled with a smaller
number of chunks than the volume was created with. The volume will then come
up in degraded state. If the volume is now detached and assembled again with
the correct number of chunks, any re-added chunks will require a rebuild.

Consequently, assembling RAID1C volumes requires careful attention to the
chunks passed via 'bioctl -l'. If a chunk is accidentally omitted from the
command line during volume assembly, then this chunk will need to be rebuilt.

At least one known-good chunk is required in order to assemble the volume.

Like CRYPTO, RAID1C supports passphrase and key-disk authentication.
Key-disk based volumes are assembled automatically if the key disk is present
while the system is booting up.

Unlike CRYPTO and RAID1, there is no boot support for RAID1C yet.

RAID1C largely reuses existing code of RAID1 and CRYPTO disciplines.
At present RAID1C's discipline-specific data structure is shared with that
of the CRYPTO discipline to allow re-use of existing CRYPTO code. A custom
RAID1C data structure would require CRYPTO code to access struct sr_crypto
via a pointer instead of via a member field of struct sr_discipline.

ok jsing@

Retire asynchronous crypto API as it is no longer required by any driver and
adds unnecessary complexity. Dedicated crypto offloading devices are not common
anymore. Modern CPU crypto acceleration works synchronously, eliminating the need
for callbacks.

Replace all occurrences of crypto_dispatch() with crypto_invoke(), which is
blocking and only returns after the operation has completed or an error occured.
Invoke callback functions directly from the consumer (e.g. IPsec, softraid)
instead of relying on the crypto driver to call crypto_done().

ok bluhm@ mvs@ patrick@

The function crypto_dispatch() never returns an error. Make it
void and remove error handling in the callers.
OK patrick@ mvs@

Refactor softraid crypto code to allow use of a discipline-specific data
structure for RAID1C volumes, as requested by jsing@ during review of my
initial RAID1C patch.

This should effectively be a cosmetic change. The point of this exercise
is to allow the data structure changes made here in softraidvar.h.

Tested on CRYPTO and RAID1C by Josh Grosse, Matthias Schmidt, and myself.
ok jsing@

change discipline name from "RAID1C" to "RAID 1C" to match the man pages

Add a RAID1C (raid1 + crypto) softraid(8) discipline.

The RAID1C discipline encrypts data like the CRYPTO discipline, and accepts
multiple chunks during creation and assembly like the RAID1 discipline.

To deal with failing disks a RAID1C volume may be assembled with a smaller
number of chunks than the volume was created with. The volume will then come
up in degraded state. If the volume is now detached and assembled again with
the correct number of chunks, any re-added chunks will require a rebuild.

Consequently, assembling RAID1C volumes requires careful attention to the
chunks passed via 'bioctl -l'. If a chunk is accidentally omitted from the
command line during volume assembly, then this chunk will need to be rebuilt.

At least one known-good chunk is required in order to assemble the volume.

Like CRYPTO, RAID1C supports passphrase and key-disk authentication.
Key-disk based volumes are assembled automatically if the key disk is present
while the system is booting up.

Unlike CRYPTO and RAID1, there is no boot support for RAID1C yet.

RAID1C largely reuses existing code of RAID1 and CRYPTO disciplines.
At present RAID1C's discipline-specific data structure is shared with that
of the CRYPTO discipline to allow re-use of existing CRYPTO code. A custom
RAID1C data structure would require CRYPTO code to access struct sr_crypto
via a pointer instead of via a member field of struct sr_discipline.

ok jsing@

The function crypto_dispatch() never returns an error. Make it
void and remove error handling in the callers.
OK patrick@ mvs@

Refactor softraid crypto code to allow use of a discipline-specific data
structure for RAID1C volumes, as requested by jsing@ during review of my
initial RAID1C patch.

This should effectively be a cosmetic change. The point of this exercise
is to allow the data structure changes made here in softraidvar.h.

Tested on CRYPTO and RAID1C by Josh Grosse, Matthias Schmidt, and myself.
ok jsing@

change discipline name from "RAID1C" to "RAID 1C" to match the man pages

Add a RAID1C (raid1 + crypto) softraid(8) discipline.

The RAID1C discipline encrypts data like the CRYPTO discipline, and accepts
multiple chunks during creation and assembly like the RAID1 discipline.

To deal with failing disks a RAID1C volume may be assembled with a smaller
number of chunks than the volume was created with. The volume will then come
up in degraded state. If the volume is now detached and assembled again with
the correct number of chunks, any re-added chunks will require a rebuild.

Consequently, assembling RAID1C volumes requires careful attention to the
chunks passed via 'bioctl -l'. If a chunk is accidentally omitted from the
command line during volume assembly, then this chunk will need to be rebuilt.

At least one known-good chunk is required in order to assemble the volume.

Like CRYPTO, RAID1C supports passphrase and key-disk authentication.
Key-disk based volumes are assembled automatically if the key disk is present
while the system is booting up.

Unlike CRYPTO and RAID1, there is no boot support for RAID1C yet.

RAID1C largely reuses existing code of RAID1 and CRYPTO disciplines.
At present RAID1C's discipline-specific data structure is shared with that
of the CRYPTO discipline to allow re-use of existing CRYPTO code. A custom
RAID1C data structure would require CRYPTO code to access struct sr_crypto
via a pointer instead of via a member field of struct sr_discipline.

ok jsing@

Refactor softraid crypto code to allow use of a discipline-specific data
structure for RAID1C volumes, as requested by jsing@ during review of my
initial RAID1C patch.

This should effectively be a cosmetic change. The point of this exercise
is to allow the data structure changes made here in softraidvar.h.

Tested on CRYPTO and RAID1C by Josh Grosse, Matthias Schmidt, and myself.
ok jsing@

change discipline name from "RAID1C" to "RAID 1C" to match the man pages

Add a RAID1C (raid1 + crypto) softraid(8) discipline.

The RAID1C discipline encrypts data like the CRYPTO discipline, and accepts
multiple chunks during creation and assembly like the RAID1 discipline.

To deal with failing disks a RAID1C volume may be assembled with a smaller
number of chunks than the volume was created with. The volume will then come
up in degraded state. If the volume is now detached and assembled again with
the correct number of chunks, any re-added chunks will require a rebuild.

Consequently, assembling RAID1C volumes requires careful attention to the
chunks passed via 'bioctl -l'. If a chunk is accidentally omitted from the
command line during volume assembly, then this chunk will need to be rebuilt.

At least one known-good chunk is required in order to assemble the volume.

Like CRYPTO, RAID1C supports passphrase and key-disk authentication.
Key-disk based volumes are assembled automatically if the key disk is present
while the system is booting up.

Unlike CRYPTO and RAID1, there is no boot support for RAID1C yet.

RAID1C largely reuses existing code of RAID1 and CRYPTO disciplines.
At present RAID1C's discipline-specific data structure is shared with that
of the CRYPTO discipline to allow re-use of existing CRYPTO code. A custom
RAID1C data structure would require CRYPTO code to access struct sr_crypto
via a pointer instead of via a member field of struct sr_discipline.

ok jsing@

change discipline name from "RAID1C" to "RAID 1C" to match the man pages

Add a RAID1C (raid1 + crypto) softraid(8) discipline.

The RAID1C discipline encrypts data like the CRYPTO discipline, and accepts
multiple chunks during creation and assembly like the RAID1 discipline.

To deal with failing disks a RAID1C volume may be assembled with a smaller
number of chunks than the volume was created with. The volume will then come
up in degraded state. If the volume is now detached and assembled again with
the correct number of chunks, any re-added chunks will require a rebuild.

Consequently, assembling RAID1C volumes requires careful attention to the
chunks passed via 'bioctl -l'. If a chunk is accidentally omitted from the
command line during volume assembly, then this chunk will need to be rebuilt.

At least one known-good chunk is required in order to assemble the volume.

Like CRYPTO, RAID1C supports passphrase and key-disk authentication.
Key-disk based volumes are assembled automatically if the key disk is present
while the system is booting up.

Unlike CRYPTO and RAID1, there is no boot support for RAID1C yet.

RAID1C largely reuses existing code of RAID1 and CRYPTO disciplines.
At present RAID1C's discipline-specific data structure is shared with that
of the CRYPTO discipline to allow re-use of existing CRYPTO code. A custom
RAID1C data structure would require CRYPTO code to access struct sr_crypto
via a pointer instead of via a member field of struct sr_discipline.

ok jsing@

Add a RAID1C (raid1 + crypto) softraid(8) discipline.

The RAID1C discipline encrypts data like the CRYPTO discipline, and accepts
multiple chunks during creation and assembly like the RAID1 discipline.

To deal with failing disks a RAID1C volume may be assembled with a smaller
number of chunks than the volume was created with. The volume will then come
up in degraded state. If the volume is now detached and assembled again with
the correct number of chunks, any re-added chunks will require a rebuild.

Consequently, assembling RAID1C volumes requires careful attention to the
chunks passed via 'bioctl -l'. If a chunk is accidentally omitted from the
command line during volume assembly, then this chunk will need to be rebuilt.

At least one known-good chunk is required in order to assemble the volume.

Like CRYPTO, RAID1C supports passphrase and key-disk authentication.
Key-disk based volumes are assembled automatically if the key disk is present
while the system is booting up.

Unlike CRYPTO and RAID1, there is no boot support for RAID1C yet.

RAID1C largely reuses existing code of RAID1 and CRYPTO disciplines.
At present RAID1C's discipline-specific data structure is shared with that
of the CRYPTO discipline to allow re-use of existing CRYPTO code. A custom
RAID1C data structure would require CRYPTO code to access struct sr_crypto
via a pointer instead of via a member field of struct sr_discipline.

ok jsing@