Adding security-warnings to #[must_use]

[brycx]

Functions that return a Result generate a warning when these are not used:

warning: unused `std::result::Result` that must be used
   --> src/high_level_api.rs:111:5
    |
111 |     orion::aead::seal(&aead_key, "Test".as_bytes());
    |     ^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^
    |
    = note: #[warn(unused_must_use)] on by default
    = note: this `Result` may be an `Err` variant, which should be handled

This is the standard warning for a Result, but adding an explicit security warning to these functions may help users understand the importance of not ignoring a Result. Adding this would then produce two separate warnings by the compiler:

#[must_use = "SECURITY WARNING: Ignoring a Result may have security-implications."]

warning: unused `std::result::Result` that must be used
   --> src/high_level_api.rs:111:5
    |
111 |     orion::aead::seal(&aead_key, "Test".as_bytes());
    |     ^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^
    |
    = note: #[warn(unused_must_use)] on by default
    = note: this `Result` may be an `Err` variant, which should be handled

warning: unused return value of `orion::aead::seal` that must be used
   --> src/high_level_api.rs:111:5
    |
111 |     orion::aead::seal(&aead_key, "Test".as_bytes());
    |     ^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^
    |
    = note: SECURITY WARNING: Ignoring a Result may have security-implications.

The question is whether this approach is worthwhile.

Edit: If this is decided against, then we should remove the useless #[must_use] on Result as mentioned in #89.

[brycx]

I have gotten positive feedback on this and it will therefor be implemented. This is based on the same assumption as mentioned above: that users hopefully will be more cautious about ignoring such Results which can have a security-impact. The error message that seemed most clear and concise was:

"SECURITY WARNING: Ignoring a Result can have real security implications."

[brycx]

@colelawrence expressed interest and is taking this on.

[brycx]

Fixed in #95.