Replace ratcheting section with stub

Author: jpbetz

keps/sig-api-machinery/5073-declarative-validation-with-validation-gen/README.md

@@ -1014,21 +1014,10 @@ Subresources such as `pods/exec`, `pods/attach`, and `pods/portforward` do not r
 
 ### Ratcheting
 
-As `validation-gen`‘s go validation code has old object access we can write any transition rule we want for validation ratcheting. `validation-gen` has access to the old and new state of obj for any field.  This gives us a building block to make any flavor of ratcheting we would need in theory.  We can think the basic form of ratcheting as - “allow old value to be written in updates even if now not valid as long as it doesn’t change -> easy to test”.  If old = new -> short circuit validation (don’t care if it failed).  If certain ratcheting needs syntactic sugar, we can add that as well based ont the current `validation-gen` design. An example of what ratcheting validation logic might look like for `validation-gen` is below:
+TODO: Document and explain how:
 
-```go
-// Tightened validation (also known as ratcheting validation) would be supported by
-// defining a new validation function. For example:
-//
-        func TightenedMaxLength(opCtx operation.Context, fldPath *field.Path, value, oldValue *string) field.ErrorList {
-          if oldValue != nil && len(MaxLength(opCtx, fldPath, oldValue, nil)) > 0 {
-            // old value is not valid, so this value skips the tightened validation
-            return nil
-          }
-          return MaxLength(opCtx, fldPath, value, nil)
-        }
-
-```
+- Add general purpose ratcheting to automatically skip validation of unchanged fields
+- Catalog and handle complex cases where strict equality checks are not sufficient (lots of non-trivial cases exist today)
 
 ### Test Plan