Fix buffer-overrun bug in net

[shirleyquirk]

there is no ctype that maps to uint8 in system.nim, instead both cchar and cuchar map to char, this is an annoying asymmetry
https://forum.nim-lang.org/t/7790 and means there's no 'byte'-like ctype that doesn't also map to string functions.

I created this PR to see what it would break, and it actually highlighted a bug in net that wouldn't have been possible to make had cuchar been defined otherwise.

SSL has these two functions for setting callbacks to send identity and psk

void SSL_CTX_set_psk_server_callback(SSL_CTX *ctx,
       unsigned int (*callback)(SSL *ssl, const char *identity,
       unsigned char *psk, int max_psk_len));
void SSL_set_psk_server_callback(SSL *ssl,
       unsigned int (*callback)(SSL *ssl, const char *identity,
       unsigned char *psk, int max_psk_len));

note the distinction between const char* identity and unsigned char* psk, identity is a null-terminated string, while psk is a byte buffer. attempting to use string routines on psk in C would have failed with a type error, while in Nim since ptr cuchar aliases ptr char aliases cstring, they don't. In this situation, C has stricter typing than Nim!

and that's what happened, here psk.len was called by mistake instead of pskString, which should have failed.

This is obviously a breaking change for someone, so feel free to just accept the net bugfix and delete the change to system if unwanted, but the fix is a powerful argument for making the break so not splitting them apart yet

[Araq]

Gah this is nasty ... You could have found this a couple of hours earlier before our new bugfix releases... :-/

[shirleyquirk]

heh. sorry should wake up earlier

[Araq]

Sorry, we need a separate PR with just the bugfix so that it can be backported easily.

[shirleyquirk]

looking a bit deeper, I dont think it's necessary to backport

hear me out:

because of #11280, which exists in 1.0.10 and 1.2.12 (in fact since 0.16)
pskCallBackServerFun and pskCallBackClientFun both cause a SIGSEGV when they try to access the identity/psk function
before they would trigger the buffer overrun

the fundamental issue is that the callback can only access the raw ssl context, not the wrapper, so, even if a pointer to the helper functions is stored in ssl_ex_data, the callback can't know at what index it's stored. assuming it's stored at zero doesn't seem to work either: #4406

making (Server|Client)GetPskFunction= work properly would require changing a lot of code, as @dom96 said: it's not trivial.
perhaps a macro that injects user code directly into the callback function? i'll have a play

I've split off the uint8 stuff from this PR anyway, just in case someone uses the sourcecode as a template, but this aint over

[timotheecour]

@shirleyquirk the root cause is #13790 (see also WIP #13792)