When trying to clean up by moving rng-tools from oe-core to meta-oe, it
became clear that we don't have a way to confirm that the entropy pool
has sufficient sources of randomness to avoid having getrandom() block for "too long". This can be a problem, especially at boot time.

rng-tools was brought back into oe-core with the following log:

> Revert this commit since:
>
>  - some systems using oe-core master may still be using kernels from
>    before 5.6 pulled in the rng-tools algorithm, and
>
>  - some hardware platforms may not have a hardware random number generator
>    and could therefore need to run rngd to avoid long boot-time initialization
>    due to a depleted entropy pool.


and this comment from me:

   The additional context that doesn't belong in the commit log
   is that we talked about this change in the YP bug review meeting
   and decided that we would keep rng-tools in oe-core for 5.0-M2
   for the two reasons given above. If we end up adding a test, as described below,
   we may never move the recipe to meta-oe.


   It seems to me that we need a test that checks if the entropy pool size
   ever falls below a critical threshold for "too long" in the first N seconds of boot time.

   Getting that test written so that: 
    - qemu VMs and
    - real HW with and without /dev/hwrng 

   all pass without the test being too permissive may take some time.


Related email threads:
https://lists.openembedded.org/g/openembedded-core/message/193798
https://lists.openembedded.org/g/openembedded-core/message/193994


Also should we document the test or how we recommend that people test their hardware?