When a storage version update is aborted because the CRD was deleted, we
don't need to reject in-flight CR requests. We can safely allow these
requests to proceed, because the CRD finalizer guarantees no write
requests can succeed after a CRD is deleted-- CREATE requests are 405
NOT ALLOWED, other requests will get 404 NOT FOUND.

In theory, "CRD deletion and CRD finalizer tearing-down CRs" could happen
in between 1. crdHandler saw CRD terminating=false and 2. crdHandler
serves CR create request.

This commit makes crdHandler read the latest CRD from the cache (shared
with CRD finalizer) right before serving the create request, to make
sure the gap is as narrow as possible, and the chance for the race is
still low.