@override is too restrictive when existing field has @requires or @provides

[clenfest]

Issue Description

When we implemented @override, we added a restriction that fields with a @requires or @provides could not be overridden, the idea being that it was dangerous to do a straight migration of these fields since leaving out these directives could be a major issue in the resolvers. The safer way to do this would be to:

1. make the overridden field @shareable
2. add the field to the new subgraph
3. remove the field from the first subgraph
4. remove the @shareable directive from the overriding subgraph

In practice, this seems too restrictive and limits the usefulness of @override. Either in certain cases (i.e. directive is the same) or potentially in all cases, we should lift this restriction.

Link to Reproduction

n/a

Reproduction Steps

No response

[awdng]

With the enterprise plan the override directive supports progressive override (ie. splitting traffic between subgraphs by percentage), would this mitigate that issue? Obviously it's an enterprise feature and not available to everyone, but I still wonder if would have helped your case. Generally speaking we found override to also be tricky in practice, even with progressive override as it requires Schema changes which makes rollbacks harder/risky.