Clarify behavior of overlapping rules and routing resolution in TrafficSplit

[mikemorris]

Describe the proposal
Currently, the behavior of resolving multiple TrafficSplit blocks with overlapping rules is left up to implementing projects. This leaves a potentially broad area of under-specified behavior which may cause unexpected routing resolutions, particularly for any users managing multiple implementing meshes or migrating from one to another.

This is likely too broad a change for the current version of the spec, but maybe something to consider in future spec versions, and/or taking steps to reduce the problem space by limiting to a single TrafficSplit block.

Scope

• Traffic Split

Possible use cases

• There may be a desire for multiple teams to write TrafficSplit rules, such as when destructuring a monolithic application into microservices, and each team managing their own microservice may want more fine-grained control such as self-managing canary deploys.
• Some meshes use "virtual" routing configuration objects to manage sub-splits with more granularity.

[mjhaller]

@mikemorris could you provide an example of the overlaps?