refactor: validation returns eithers

[XVincentX]

This PR is a start to a refactor of the validators approach.

As I mentioned somewhere, the idea is to have 3 PRs that will do the job

Here's what I did:

1. The validator generic signature now does not return a IPrismDiagnostic[], but rather an Either<NonEmptyArray<IPrismDiagnostic>, T> — which means either a validated T or an array of validation errors. https://github.com/stoplightio/prism/pull/731/files#diff-2991521f751aa9cf68976ceef512e19a
2. I have created a sequence for an Either with the applicative method modified to concat the errors, as the article we were reading about was suggesting: https://github.com/stoplightio/prism/pull/731/files#diff-d6f4104cbf0cdb51855c413bc0079241R43-R44
3. All the validators have been modified to return the Either — https://github.com/stoplightio/prism/pull/731/files#diff-ec5f393de032d67a4f08a12ecde5456cR54, and then all sequenced together to get the final request/response validation https://github.com/stoplightio/prism/pull/731/files#diff-52fafd78c752aca126e4fd8c4ce567a6R98-R103
4. All the improvements then finally converge in the factory.ts file where you can see that finally validation and mocking are two different TaskEither steps melted together with chain calls.

[XVincentX]

shouldn't the refactor address validators vs serializers in the first place? Is this something that will be addressed in the next PRs?

This will be a follow up PR. This is just the beginning of breaking it down so that we can easily at least compose the steps (route, validate input, mock, validate output, send response) that is required for Hosted Prism. We'll iterate and move on as we go.

[lag-of-death]

something more verb-ish, like:

Suggested change

	const inputValidation = (
	const getInputValidation = (

[lag-of-death]

there's a couple of these, does it mean that there's a user-facing change in Prism behavior or is it just a part of the refactor?

[karol-maciaszek]

Exactly, why the number of validation errors changed from 0 to 3?

[XVincentX]

Good question. So previously our validators were ran even if there was no need to run them. You can see it here: https://github.com/stoplightio/prism/pull/731/files#diff-52fafd78c752aca126e4fd8c4ce567a6L45-L47

You can see that the functions were called anyway even if there was nothing to validate. In the following lines instead you can see there's a check to make sure it's the case to call them or otherwise call directly Either.right

In this tests, the validators were mocked to return an error in any case, so no matter what was happening, all the validators were always called and returning an error. Body + Query + Headers = 3 validators — that explains the number.

[karol-maciaszek]

I have really no improvement requests for this PR. Some parts were mindblowing. I took me double-espresso to understand validationSequence.

I'd like to discuss that comment in context of further refactoring: https://github.com/stoplightio/prism/pull/731/files#diff-2991521f751aa9cf68976ceef512e19aR23

[karol-maciaszek]

Exactly, why the number of validation errors changed from 0 to 3?