Improve WebSocket mask handling

[marty1885]

The current WebSocket implementation triggers UBSan when applying the mask.

/home/marty/Documents/drogon/lib/src/WebSocketConnectionImpl.cc:117:9: runtime error: store to misaligned address 0x7fc50c008592 for type 'int', which requires 4 byte alignment
0x7fc50c008592: note: pointer points here
 00 00  81 86 00 00 00 00 00 00  00 00 00 00 00 00 00 00  00 00 00 00 00 00 00 00  00 00 00 00 00 00
              ^ 

Also, currently we generate the mask from std::rand(). Which is not as strong as the RFC requires. (Besides it's LCG, rand() on Windows is 15 bits)

Quote from RFC 6455 section 10.3:

   Clients MUST choose a new masking key for each frame, using an
   algorithm that cannot be predicted by end applications that provide
   data.  For example, each masking could be drawn from a
   cryptographically strong random number generator.

This patch provides three improvements

• Fix the 4 byte alignment issue
• Add API to take secure random numbers
• Uses cryptographically strong numbers for the mask
  • With a 16-elemnt cache, per-connection. 16 is a random number I came up with to not use too much memory for embedded systems users. But also large enough to not hammer the entropy source. Maybe we should change it?

It tries to generate numbers from OpenSSL if available. If not, it takes number from /dev/urandom (UNIX) or Cryptographic Services (Windows),

[an-tao]

Especially

[an-tao]

• I think fread(ptr, 1, size, fptr.get()) would be better;
• How about to use std::random_device?

[marty1885]

I think the common wisdom is to not trust std::random_device for security. Now the major STL implementations (MSVC, libc++, stdlibc++) uses /dev/random or CryptGenRandom, but the standard does not guarantee it. IIRC is was a basic PRNG before VS 2012 and earlier versions of MinGW.

Maybe it's not a concern now?

[oToToT]

I would recommend using getrandom or getentropy on linux-like or bsd-like systems (and even arc4random_buf). As they might have better performance and wouldn't consume any fd.
And probably we could use RtlGenRandom or rand_s on windows for better performance.

The idea is mainly from chromium's implementation.

• how v8 did: link
• how chromium did for posix platform: link
• how chromium did for windows platform link
• some discussion on rust-random for the scary warning of RtlGenRandom: link

[marty1885]

Now: arc4random on BSD/OSX, getentropy on Linux if we have glibc >= 2.25. Otherwise fallback to /dev/urandom. And RtlGenRandom on WIndows.

[marty1885]

I added a hack to prevent db_test crashing to cause the CI to fail. I'll work on the bug. But for now, I'll assume a abort to be a successful test. As there's no reason for db_test to abort besides the weird bug causing it to crash at the end.

Update, it should have been 134 not 255.