Revert "Add test for uvicorn worker (#631)"

[euri10]

This reverts commit 44e7deb

I now think the previous behaviour was correct, and I've been confused by the use of the same timeout word in different contexts.

Add to that the fact that as rightly written in the gunicorn doc, the -timeout gunicorn flag purpose in the async case is not the same as in the sync case, it's only used to notify the Arbitrer that workers are still alive.

To sum up the flow : when using gunicorn with the -k flag you basically spawn an Arbitrer, which spawns workers (UvicornWorker in our case), workers who need to notify the arbitrer before the -timeout flag which defaults to 30s, if not they reboot.

Now to do that, the UvicornWorker inherits the timeout from the gunicorn base Worker, and this timeout is de facto set at half the -timeout value by the Arbitrer when it spawns its workers, I was missing that part when I thought the gunicorn config was not passed down :

    def spawn_worker(self):
        self.worker_age += 1
        worker = self.worker_class(self.worker_age, self.pid, self.LISTENERS,
                                   self.app, self.timeout / 2.0,
                                   self.cfg, self.log)

so as soon as a UvicornWorker is initialized, it has its notification timeout set to that half and should we change the -timeout gunicorn flag it would be correctly reflected in the UvicornWorker configuration.

[tomchristie]

Gotcha, thanks.

We may also want to revert #646 and then issue a release? (Then we can take a second pass a figuring out a more precise method for allowing different reload files to be specified)