consider allowing unknown fields in the webhooks

[dprotaso]

Our upgrade/downgrade test is very good at catching inclusion of new fields

ie. from #11038 (comment)_

"Failed to migrate: unable to patch resource serving-tests/pizzaplanet-post-upgrade-service-00001 (gvr: serving.knative.dev/v1, Resource=revisions) - admission webhook "webhook.serving.knative.dev" denied the request: mutation failed: cannot decode incoming new object: json: unknown field "actualReplicas""

To have downgrade tests passing I've see two approaches:

1. Work around this by adding fields in two releases. This approach poses challenges if we'd like to introduce a new field with a non-zero default value.
2. Relax this constraint and accept the world. This removes safe guards and user validation

[dprotaso]

A third more extreme option may be to take an official stance and not support downgrading - and remove the test. (probably a non-starter)

[dprotaso]

I'm leaning towards option #1 keep the status quo - I think defaulting could be done after the fact

[dprotaso]

Gonna to close this off - as I opened it to prompt a discussion but that didn't happen and I think the status quo is still the right approach.