Add support for one zero and yes no boolean strings in environement variables provider

[Adobels]

Motivation

Add support for 1, 0, and YES, NO boolean strings in EnvironmentVariablesProvider. Support for YES and NO boolean strings was not discussed in the original issue. From personal experience, I found it interesting to include it. If rejected, I will remove it. I tried to remain consitent with the existing decoders and the way they are used by the provider.

Closes #110

Modifications

The EnvironmentVariablesProvider's bool decoder is configurable and can be initialized with support for true/false, 1/0, yes/no, or any combination of them.

Result

Usage of EnvironmentVariablesProvider has not changed, but by default all pairs of boolean strings are accepted when retrieving values as Bool or BoolArray. Client code can configure the provider to use a bool decoder with support only for true/false strings.

If it is more important to keep the behavior as it was, meaning default support for true/false only in the provider, then I will modify the default set for the EnvironmentVariablesProvider BoolDecoder.

Test Plan

The decoder is tested with dedicated tests, and additional tests for receiving a value from a provider were added to test the integration of BoolDecoder with EnvironmentVariablesProvider.

Code is commented, and tests are green locally.

[czechboy0]

Thank you @Adobels! A few pieces of feedback:

• I appreciate you future-proofing this by making the string-to-bool decoder customizable, but let's not add that to the API yet. We can always add it in the future, but for now please make it an implementation detail and hardcode to the logic you chose.
• I do like supporting YES/NO as well, I don't expect this to cause confusion and many other systems support this too.
• In the tests, please don't expand the default set of values, create a dedicated test that exhaustively tests these various Boolean variants.

And just FYI, I'm going on vacation so my responses will be slower until early January.

[Adobels]

The stringToBool test iterates over cases and highlights the input, making it easy to identify a specific string that causes a problem. Tests/ConfigurationTests/ConfigBoolsFromStringDecoderTests.swift:31

Comments have been addressed, and the PR is ready for review.

[Adobels]

decodeBool is now part of EnvironmentVariablesProvider.Snapshot as a static member, to avoid a dependency on a Snapshot instance in tests.

decodeBool could be made private, but that would prevent direct unit tests and would require testing only through an EnvironmentVariablesProvider instance. If it is set to private, the two other decoders should be set to private as well.

I am ready for review.

[czechboy0]

Suggested change

	default: nil
	default: Bool(string)

Let’s use the built-in parser as a fallback.

[Adobels]

The documentation of Bool says:
If the description value is any string other than "true" or "false", the result is nil. This initializer is case-sensitive.

The modification leads to calling the Bool initializer, which is already covered by the switch and will therefore always return nil. It leads also to a question: Why Bool uses string instead of stringLowercased? This increases future maintenance

What is your reasoning behind using Bool(string)?

Another possibility is:

        static func decodeBool(from string: String) -> Bool? {
            let stringLowercased = string.lowercased()
            return switch stringLowercased {
            case "yes", "1": true
            case "no", "0": false
            default: Bool(stringLowercased)
            }
        }

[czechboy0]

Ah yes, stringLowercased, my point was more to still run through the initializer as a fallback.