Field sharing/enforcing source-of-truth for entities

[pcmanus]

One of the underpinning of federation 2 is a more principled approach to which subgraphs can be allowed to compose and which cannot. Essentially, the code aims at allowing composition if 1) the subgraphs can merge meaningfully and 2) it can prove that all queries expressible on the result of composition can be query-planned. This mechanism allows a fair bit more flexibility than federation 1 on purpose, but some of that flexibility is only useful in specific cases and we should ideally make sure it is used intentionally.

One particular area of concerns is the ability for fields of types representing entities to be defined in multiple subgraphs: doing so can easily lead to some inconsistency for the entity if care is not applied and the various resolvers of the field are not "kept in sync". To be clear, allowing an entity field to be resolved by multiple graph (which is very much akin to the concept of denormalization in database) has its use (for performance), and should be allowed. But we believe it should not be the default (it is the default with the current federation 2 alpha code, and that issue is about a solution to change that).

Do note that this notion of not allowing fields of entities to be defined in multiple subgraphs by default is reminiscent of what federation 1 type ownership enforced. Essentially, federation 1 type ownership came with a number of limitations, and federation 2 is about removing those limitations, but the one limitation of type ownership that we want to preserve (in a new and hopefully improved way) is the ability to reason, by default, about a "source of truth subraph" for fields of an entity type.

This ticket is about defining (and ultimately implement) the exact mechanism by which federation 2 allow to reason about when a field can and cannot be defined in multiple subgraphs, and ensure the defaults of this mechanism are reasonable.

[pcmanus]

I'll note that this was solved through the introduction of @shareable in #1510.