chore: migrate preconditions to use non-null error messages

[ata-nas]

Description

Migrate the preconditions class to use non-null error messages as seen in this comment

e.g.

    private static final String OUT_OF_RANGE_DEFAULT_MESSAGE =
            "The input value [%d] is required to be in the range [%d, %d], inclusive.";
    /**
     * This method asserts a given int is within a range (boundaries
     * included). If the given int is within the range, then we return it,
     * else, an {@link IllegalArgumentException} is thrown.
     *
     * @param toCheck the int value to test
     * @param lowerBoundary the lower boundary
     * @param upperBoundary the upper boundary
     * @return the input {@code toCheck} if it is within the range (boundaries
     * included)
     * @throws IllegalArgumentException if the input int does not pass the test
     */
    public static int requireInRange(final int toCheck, final int lowerBoundary, final int upperBoundary) {
        return requireInRange(toCheck, lowerBoundary, upperBoundary, OUT_OF_RANGE_DEFAULT_MESSAGE);
    }
    /**
     * This method asserts a given int is within a range (boundaries
     * included). If the given int is within the range, then we return it,
     * else, an {@link IllegalArgumentException} is thrown.
     *
     * @param toCheck the int value to check
     * @param lowerBoundary the lower boundary
     * @param upperBoundary the upper boundary
     * @param errorMessage A format string {@see Formatter#syntax} with three
     *     decimal parameters for {@code toCheck}, {@code lowerBoundary},
     *     and {@code upperBoundary}.<br/>
     *     Example: {@code "The input (%d) is out of range (%d, %d)"}
     * @return the input {@code toCheck} if it is within the range (boundaries
     * included)
     * @throws IllegalArgumentException if the input int does not pass the test
     */
    public static int requireInRange(
            final int toCheck, final int lowerBoundary, final int upperBoundary, @NonNull final String errorMessage) {
        if (toCheck >= lowerBoundary && toCheck <= upperBoundary) {
            return toCheck;
        } else {
            final String message = errorMessage.formatted(toCheck, lowerBoundary, upperBoundary);
            throw new IllegalArgumentException(message);
        }
    }

[ata-nas]

@jsync-swirlds something I have been thinking about, if we do move to this approach, then we would be computing the formatting of the error message every time the method with the default message is invoked. That is redundant since we generally do not expect to have to use this message. This seems like it would have a slight performance hit? Yet again the JVM does a lot of magic behind the scenes, I am unaware if it has some optimizations for such cases, although I would not rely on that. With the current implementation, the default message is computed only after the precondition checks have already failed.

That being said, I think we can omit this change, if this will hurt the performance, which I think it will do, preconditions are used everywhere.

Other option would be to have the default messages not compute anything, but that does not allow us to log values used. Of course, this is what the overload is for, in case we want to add a custom message, but I fear that it would be a great hustle to have to manually interpolate an error message where we need to use the precondition, just to get something that I would generally expect by default. I think the overload to provide a custom message should be used only if it is absolutely necessary and in places where it would hardly be invoked if it would be the case where our custom message will have to be prematurely computed.

I do agree about the point about the error message to not be null which can be enforced with static code analysis, but if the negatives of us having to basically interpolate a String prematurely without actually expecting to use it, we should probably consider to not move on with this.

Opinion?

[jsync-swirlds]

Producing the message is fairly inexpensive, but if we want to be extra efficient, it isn't hard to do both (make non-null constraint and also only perform interpretation when needed).
Basically, just make the message the format string, and do the interpretation when needed, but still handle the default part via method overload so we get better static analysis.