Key issues can cause bad data to be returned from the cache

tl;dr—FieldEncryptDatabaseCache::prepareItem will return false for the data of a cached item if decryption failed due to exceptions getting blocked in field_encrypt_decrypt

Here is what happened:

1. Something "broke" encryption while our cache was full of encrypted items. In our case the issue was a key getting swapped.
2. Now, the cache is set but still exists. The cache class calls FieldEncryptDatabaseCache::prepareItem on the cache item. $cache->data is set to the encrypted serialized data. The cache is OK so we don't ignore it. Next, decryption occurs.
3. During decryption, we go into $this->encrypt() which in turn calls field_encrypt_decrypt. Herein lies the problem.
4. Decryption fails and throws an Exception stating that the HMAC failed validation (or that the key didn't load). The Exception is caught on line 325 and then null is returned on line 326. The exception is handled.
5. Going back up the chain, the catch block doesn't get called because the Exception thrown during decryption was already handled in field_encrypt_decrypt. Yuck.
6. Lastly, the code continues processing, so it continues. However, null was returned and now $cache->data gets set to unserialize(null); aka false.

The impact that this caused us was that a call to field_info_field_map returned false while processing in Lockr's field encrypt override module. This then caused massive pain and downtime as now more and more fields became cached and encrypted, compounding the problem.

However, it seems like this needs to be fixed anyway such that a cache failure checks for a bad decrypt and fails the cache rather than setting false.