crypto: chachapoly availble in /dev/crypto

[FelipeMdeO]

Summary

Adds a raw CRYPTO_CHACHA20 stream-cipher algorithm to the OCF crypto framework (/dev/crypto), needed because SSH's chacha20-poly1305@openssh.com uses two independent ChaCha20 keystreams and doesn't match the existing combined CRYPTO_CHACHA20_POLY1305 xform

Also adds a sim:dropbear board config combining networking and Dropbear so the SSH server can be exercised locally without hardware.

Related PR: apache/nuttx-apps#3626, which consumes this to back Dropbear's chacha20-poly1305@openssh.com cipher via /dev/crypto. Both are draft PRs meant to be reviewed together.

Impact

New opt-in crypto algorithm and a new sim-only board config; no changes to existing algorithms or configs.

Testing

Host: Linux x86_64, sim target.

This Implementation was tested using apache/nuttx-apps#3626, result logs can be checked there.

[github-actions]

MemBrowse Memory Report

No memory changes detected for:

• arduino-mega2560
• esp32-devkitc
• hifive1-revb
• mirtoo
• qemu-armv8a
• qemu-intel64
• rx65n-rsk2mb
• s698pm-dkit
• stm32-nucleo-f103rb

[ThePassionate]

Thanks for working on this. I'd suggest a different, more unified approach here rather than adding a parallel encrypt_multi/decrypt_multi path with new chacha20_stream_* helpers.

The framework already supports stream ciphers through the existing encrypt/decrypt callbacks (e.g. AES-CTR/OFB/CFB). Rather than forking the interface into a separate stream path, we can just extend the existing encrypt/decrypt signature to carry a length:
CODE void (*encrypt)(caddr_t, FAR uint8_t *, size_t len);
CODE void (*decrypt)(caddr_t, FAR uint8_t *, size_t len);
With that single change:

swcr_encdec handles a partial final block via buflen = MIN(i, blocksize), so arbitrary-length stream data flows through the existing single path.
chacha20_crypt just gains a len argument and keeps leftover keystream bytes across calls (keystream8[64] + keystream_bytes_used) to keep the stream continuous.
The enc_xform_chacha20 entry reuses the existing chacha20_crypt/setkey/reinit — no new symbols, no special-case branch.
This keeps all ciphers (block and stream) on one uniform path instead of maintaining two. Any future stream cipher then drops in with just an xform table entry. Exposing both encrypt_multi and the block callbacks adds a second parallel code path that we'd have to keep in sync long term, which I think is best avoided.

I already have a patch implementing this (extending the encrypt/decrypt signature + chacha20 export on the unified path). I'm happy to share it so we can align on the unified approach.