Split AllocationDecider into sub-interfaces and group deciders

[mhl-b]

This change splits AllocationDecider into collection of interfaces. This should help with applying deciders that implement interfaces rather than calling all of them with default "Decision.ALWAYS" result. Every decider now explicitly tell which interface it implements:

public class DiskThresholdDecider extends AllocationDecider {
// become
public class DiskThresholdDecider
    implements
        AllocationDecider.ShardToNode,
        AllocationDecider.ForceDuringReplace,
        AllocationDecider.ShardRemain {

So AllocationDeciders can use this type information to group deciders for specific API call.

    public Decision canAllocate(ShardRouting shardRouting, RoutingAllocation allocation) {
        return withDeciders(
            allocation,
            shardToClusterDeciders, // explicitly pass which deciders to use
            decider -> decider.canAllocate(shardRouting, allocation),
            (decider, decision) -> Strings.format("Can not allocate [%s] on any node. [%s]: %s", shardRouting, decider, decision)
        );
    }

For testing ease added a new class DefaultAllocationDecider that uses previous behaviour of abstract class with "Decision.ALWAYS".

Major change in AllocationDecider and AllocationDeciders. I do preserve default behaviour. Especially for ShardToNode decider that combines canAllocate, canForceAllocatePrimary, and canAllocateReplicaWhenThereIsRetentionLease, since later two depends on canAllocate.

[elasticsearchmachine]

Pinging @elastic/es-distributed-coordination (Team:Distributed Coordination)

[mhl-b]

Should probably move to test package. Production deciders implement interfaces. This one only for testing.

[DaveCTurner]

I don't like this much, it seems much more complicated and the benefits are pretty minimal. It makes the job of someone implementing a decider (often from outside the distrib/allocation team these days) even more complicated than it is already.

[mhl-b]

Sad to hear. I'm still liking how it looks, explicit and yet minimal, easier to read and navigate, no hidden defaults. Some deciders are orthogonal to each other but share same defaults, which is counter intuitive. I will keep this PR open for now.

[DiannaHohensee]

This significantly complicates the AllocationDeciders. Adding a new AllocationDecider method would require creating a new interface.

If we were to prove that the current code has significant performance loss in the AllocationDeciders calls, compared to your PoC, then paying the complexity cost could be of interest. But without that proof I think this proposal only has downsides.

[mhl-b]

Adding a new AllocationDecider method would require creating a new interface.

It does not. Adding new method to AllocationDecider requires new interface. Implementation of decider chooses a set of interfaces it wants to implement.

[mhl-b]

even more complicated

complexity cost

I see this as perceived complexity, due to more verbose "implement" statement. But it's explicit what each decider suppose to do. Real complexity reduces since every decider has smaller surface, no defaults.

I dont see reasons for these defaults to exists. AllocationDeciders uses "YES" by default when looping through it's deciders. Changing default to something non-yes, will break everything.