container retain fix

[tanner0101]

Fixes a crash created by #1878. Fixes #1895, #1894.

• Add failing test case
• Implement fix

[tanner0101]

The problem here that we didn't see during review of #1878 is that Request is a ContainerAlias to its shared container. Because of this, when you call req.client(), the container for the created client is actually that Request. Even though it redirects all calls to its underlying shared container. If you don't hold a strong reference to the request, it will deinitialize and the next request to access that client from the cache will get a Client with no container.

This fix is to make req.client() use the sharedContainer explicitly. This container is kept alive by the application until it shuts down.

[penny-coin]

Hey @tanner0101, you just merged a pull request, have a coin!

You now have 1057 coins.

[valeriomazzeo]

These changes have completely broken my application (which I had almost finished migrating...).

Apart from the obvious changes which I was able to fix, see for example: asensei/vapor-auth-jwt@ce5ed30

There are some which I am not clear how to fix:

public func didBoot(_ worker: Container) throws -> EventLoopFuture<Void> {
  // I was using worker.client() here

  // Also sometimes: let o = try worker.myCustomObject()
}

Also, are these changes suggesting that custom Container extensions should be now implemented on Application or Request ? I have plenty of internal providers that were following this pattern:

public extension Container {

    public func myCustomObject() throws -> MyCustomObject {

        let config = try self.make(Provider.Config.self)

        return ...
    }
}