## Description 

This failure scenario is found via `access_clock_object_test`:

1. Fullnode runs quorum driver to execute a transaction with input clock
object version 5.
2. Clock object v5 is returned from validators along with effects.
Fullnode clock version is currently 1, but regardless it writes v5 clock
into the objects table.
3. Fullnode tries to execute the transaction locally. Before execution,
transaction manager reads clock v5, found it exists in db, and updates
the `AvailableObjectCache`. The `AvailableObjectCache` starts to assume
all versions <= 5 of the clock object exist in the objects table.
4. Afterwards, executing a transaction with input version < 5 can panic,
because once the transaction starts executing, it will not be able to
find the input clock object.

There are a few possible mitigations:
1. Disable caching clock object.
2. Remove the object via QuorumDriverResponse path.

I picked (1) here which seems to be the least delta for now.

## Test Plan 

Rerun `access_clock_object_test`

---
If your changes are not user-facing and not a breaking change, you can
skip the following section. Otherwise, please indicate what changed, and
then add to the Release Notes section as highlighted during the release
process.

### Type of Change (Check all that apply)

- [ ] protocol change
- [ ] user-visible impact
- [ ] breaking change for a client SDKs
- [ ] breaking change for FNs (FN binary must upgrade)
- [ ] breaking change for validators or node operators (must upgrade
binaries)
- [ ] breaking change for on-chain data layout
- [ ] necessitate either a data wipe or data migration

### Release notes