Make MIN_DIST_PATH configurable within the settings

[Not-a-Tyler]

Makes it so much easier to do automation in zenith, goal nears wont try to go to the exact block you want, they will only get within the goal near distance and quit, and goal blocks will always try to build to get to the exact block position instead of going to closest position.

[github-actions]

Please do not open pull requests from branches of the same name (e.g. '1.21.4'), create a new branch instead

[rfresh2]

i looked into why baritone uses 5 blocks

https://docs.google.com/document/d/1WVHHXKXFdCR1Oz__KtK8sFqyvSwJN_H4lftkHFgmzlc

This is why we pick the first one that results in the best node being more than 5 blocks away; in testing we found that if the best node is more than 5 blocks away, it’s probably going to go for as far as it can (probably dozens of blocks), because the slope of H(n)+C(n)/x is negative. So basically we are trying to pay attention to cost as much as possible, while still making sure that we get at least five blocks, which means that it will probably go as far as it can.

and i think i have another solution

public Optional<IPath> bestSoFar(final int numNodes) {
    return bestSoFar(numNodes, MIN_DIST_PATH).or(() -> bestSoFar(numNodes, 1));
}

public Optional<IPath> bestSoFar(int numNodes, double minDist) {
	...
    for (int i = 0; i < COEFFICIENTS.length; i++) {
		...
        if (dist > minDist * minDist) { // square the comparison since distFromStartSq is squared
            return Optional.of(new Path(realStart, startNode, bestSoFar[i], numNodes, goal, context));
        }
    }
    return Optional.empty();
}

we get original intent of 5 blocks, and if that fails pathing can fall back to a 1 dist min