Environment variable passing support

[brainstorm]

Adds the necessary structs/types/event for env var sending/handling (and avoids runtime message: WARN - Unknown channel req type 'env')... that's according to RFC 4254, but we'll deem more env vars as 'safe to pass' than just LANG, TERM, and DISPLAY. I.e (potentially with SSH_STAMP_ prefix):

UART_TX_PIN and UART_RX_PIN
WIFI_SSID, WIFI_PW
GENERATE_HOST_KEY
PUBLIC_KEY, etc...

This PR is essential to implement support on brainstorm/ssh-stamp#44.

/cc @mmalenic

[brainstorm]

Yay, working now:

[src/serve.rs:98] "Got ENV request" = "Got ENV request"
[src/serve.rs:99] a.name()? = "LANG"
[src/serve.rs:100] a.value()? = "C.UTF-8"
[src/serve.rs:41] &ev = ServEvent(PollAgain)
[src/serve.rs:41] &ev = ServEvent(Environment)
[src/serve.rs:98] "Got ENV request" = "Got ENV request"
[src/serve.rs:99] a.name()? = "UART_RX_PIN"
[src/serve.rs:100] a.value()? = "10"

Will cleanup (remove ipv6 cfg that doesn't belong here) and mark it ready for review later on. Done!

@mkj Please review? :)

[mkj]

Thanks, this looks good. One small comment on naming.

The docs could maybe have a note that the strings are not sanitised, so if they're passed to a shell/C FFI etc the application needs to be careful (strip \0 etc). That probably applies to username/password as well - I can have a look at that, no need to hold up this PR.

[brainstorm]

The docs could maybe have a note that the strings are not sanitised, so if they're passed to a shell/C FFI etc the application needs to be careful (strip \0 etc). That probably applies to username/password as well - I can have a look at that, no need to hold up this PR.

Thanks Matt! I did think a bit about input sanitisation/validation but honestly I didn't know how much of it you wanted to include at the lib level so I left it a bit open for now... perhaps the length of both name and value should ideally be clipped to reasonable defaults while you are at it?... among other input validation standard recommendations.

[mkj]

perhaps the length of both name and value should ideally be clipped to reasonable defaults while you are at it?... among other input validation standard recommendations

I don't think the core library needs to do it - the name/value are slices of the input packet, so don't use any space beyond the fixed input buffer. On embedded platforms to keep a string copy I assume they're usually using heapless::String or similar with an upper limit, and when creating the string they'll have to be error checking the constructor. On non-embedded platforms I guess there might be a risk of multiple large heap allocations, but that's a bit hard to prevent from Sunset's side.