Add efi_rng opt-in backend

[newpavlov]

The implementation is based on the std code. I am not sure why we need the try loop over protocol handles instead of just getting the first handle, but I decided to just follow std here.

Because the backend requires access to BootServices it has to rely on the unstable uefi_std feature. We could alternatively use the uefi crate, but it would tie the backend to the uefi crate environment, which is probably not desirable.

TEMP_EFI_ERROR is used as a temporary solution until #568 is resolved, which I plan to do in a separate PR.

cc @usamoi @nicholasbishop

[josephlr]

Do we need TEMP_EFI_ERROR now if we have #569 ?

[newpavlov]

As I wrote in the OP, to encapsulate the UEFI status codes we need a wider state than 32-bits. Technically, on x86-64 we need 64 bits, but we probably can use NonZeroU64 since status codes with prefixes 0x1, 0x3, and 0x7 are used for "warning" codes.

[josephlr]

Two questions:

• Do we think that adding in this backend is a blocker for 0.3?
• Is there a reason to have this be opt-in rather than our default implementation for the UEFI target? (Especially now that an alternative backend like rdrand can be enabled even on supported targets).

[newpavlov]

Do we think that adding in this backend is a blocker for 0.3?

No, it's not a blocker and may be left for a later release.

Is there a reason to have this be opt-in rather than our default implementation for the UEFI target?

There are two reasons:

• It relies on the unstable uefi_std feature.
• IIRC on x86-64 targets the UEFI RNG protocol usually simply uses RDRAND, so users may prefer to use it directly.