Fix GRND_NONBLOCK flag when calling getrandom.

I screwed up in 56b6c714c9 and got the direction of this condition
backwards. This doesn't cause a security problem because:
  a) wait_for_entropy will ensure that the pool is initialised.
  b) if GRNG_NONBLOCK is set when not expected, any EAGAIN will
     cause an abort anyway.

However, when coupled with opportunistic entropy collection on platforms
with RDRAND, this could cause an unexpected blocking getrandom call.

This this change, `strace -e getrandom bssl rand 1` shows two getrandom
calls with GRNG_NONBLOCK set, as expected. (The first being the probe to
check whether the kernel supports getrandom, and the second being the
opportunistic entropy gathering to augment RDRAND.)

Bug: chromium:1016811
Change-Id: I98ed1cef90df510f24cf2df1fba9b886fcbf3355
Reviewed-on: https://boringssl-review.googlesource.com/c/boringssl/+/38204
Commit-Queue: Adam Langley <agl@google.com>
Commit-Queue: David Benjamin <davidben@google.com>
Reviewed-by: David Benjamin <davidben@google.com>
(cherry picked from commit f3bd757ee5)
Reviewed-on: https://boringssl-review.googlesource.com/c/boringssl/+/38504

crypto/fipsmodule/rand/urandom.c

@@ -389,7 +389,7 @@ static int fill_with_entropy(uint8_t *out, size_t len, int block, int seed) {
 
 #if defined(USE_NR_getrandom)
   int getrandom_flags = 0;
-  if (block) {
+  if (!block) {
     getrandom_flags |= GRND_NONBLOCK;
   }
   if (seed) {