Harden configuration logic

[ssciolla]

There are a couple issues with the config module validation right now that would be nice to address before we move to regular deployments.

1) If you leave a key without a value, e.g. LOG_LEVEL=, it interprets this as an empty string, which is considered valid by the string checking logic. We should add an additional check for empty strings.

2) If you specify a value that fails its validation, the fallback is still used. This logic seems somewhat dangerous for production, as you might miss a log message and accidentally use a default value. I think only using the fallback if the value is undefined would be a safer approach, basically throwing an error if an invalid value is specified.

3) The main type guards in use in config.ts are really only for strict type checking, and can't be expanded for type inferences for things like string lengths or even the isNaN I'm using now in isNumber (NaN is technically a number). We can use custom types for controlled vocabularies (like LogLevel), but I think it would be clearer if we had a separate mechanism for other checks which we might want to make, but can't be used in type inference.

Side note: I have thought about converting some of this custom validation code to use something like joi, which looks cool. I have been hesitant to thus far because some amount of type guarding and interfaces would still be necessary, and maybe I've grown attached to the control available with the current approach. I think our use case is simple enough at this point, but it's something we may want to return to in the future.

[pushyamig]

Configuration logic is handled in config.ts and it checking each type of the configurations, syntax of the value and default values logic. Test passes.