Future currently takes a non-standard approach to moves. It uses the ResetOnMoveOptional type internally, an object that implements the boost::optional API with implicit reset on move. A number of tests make the assumption that Future objects are valid after being moved-from, and even validate aspects of that behavior. These have caused pain in the v5 toolchain upgrade project in the form of compiler and clang-tidy warnings that we've had to silence.

Revisit the original decisions that created the ResetOnMoveOptional type and the tests that use-after-move intentionally. If we can avoid their uses, remove them. Otherwise, revisit the warning suppressions and either fix them or document why they are needed and why the underlying operations are safe.