Adds assertEquals() and guard() functions

[twof]

Let me know if you want them moved into their own extension files. Example usage:

User.query(on: req)
    .filter(\.email == registerRequest.email)
    .count()
    .assertEquals(0)
    .guard(elseThrow: userExistsError)
    .saveUserWith(
        name: registerRequest.name,
        email: registerRequest.email,
        password: registerRequest.password,
        on: req
    )

[bensyverson]

I'm still seeing weird behavior where an exception within guard is not bubbling up. Check out this example project which uses the proposed change. You'll need to reconfigure psql, then register a new User (call /api/v1/register or use the included Paw file).

Registering multiple users with the same email address should be prevented by guard, but it passes through. The console will read I should throw!—which is printed from the same block that throws the Error—but the Error (an Abort) is silently caught somewhere, allowing the chain to continue with a successful 200

[twof]

In reference to @bensyverson's issue, there seems to be a problem where Aborts thrown earlier in the chain will be overridden buy errors thrown later in the chain.

[twof]

Added a variadic version of assertEquals and made guard's result discardable so you can now do things like validate query results. Example:

extension QueryBuilder where Model == Reservation {
    func validNumberOfReservationsInDatabase() -> Self {
        let invalidNumberOfReservationsError = Abort(.badRequest, reason: "There are an unusual number of reservations matching that query in your DB", identifier: "Whoops")
        
        self
            .count()
            .assertEquals(0, 1)
            .guard(elseThrow: invalidNumberOfReservationsError)
        
        return self
    }
}

In this example I'm checking to see if the number of Reservations returned is either 0 or 1 and Aborting if that's not the case.

[tanner0101]

I like these methods, but not convinced (yet) they are critical enough to require in the core. These strike me as suitable for addition in a third party "helpers" package.

[Joannis]

I concur with @tanner0101

[jdmcd]

@twof Maybe you can start a helpers package in vapor-community?

[twof]

@mcdappdev I'm down. Do I need to be added to the organization or how does that work?

[jdmcd]

I believe so but I'm not positive

[twof]

Hey I'm still down to maintain (or comaintain) a repo in vapor-community if someone wants to open an AsyncHelpers repo for me

@tanner0101 @Joannis

CC @MaximBazarov

[gperdomor]

@twof @tanner0101 @Joannis @mcdappdev @bensyverson I made a repo with some extensions, please make PR for new extensions here --> https://github.com/vapor-community/vapor-extensions

[twof]

CC @MaximBazarov

[gperdomor]

I think we can close this in favor of https://github.com/vapor-community/async-extensions

[twof]

Closing this PR now that there's a community extensions package