This change makes it more so that `Loop.stop()` gracefully makes the
current iteration the final one, by waiting AND THEN returning.
The current implementation is closer to `cancel`, while also not.
I encountered this because I was trying to run a
`@tasks.loop(count=1)`, and inside it I print some text and change the
interval, and in an `after_loop`, I restart the loop.
Without this change, it immediately floods my console, due to
not waiting before executing `after_loop`.
I noticed nothing happened when I did
`ch.edit(overwrites=oh.overwrites)`
`http.edit_channel` doesn't do anything with the `overwrites` keyword,
it's processed as `permission_overwrites` instead which `self._edit`
takes care of.
I feel this was an oversight at some point.
Task cancel raises on the next awaited coro, so I've added this 0-sleep "hack"
I'm internally debating if leaving the comment there, but I'm sure it would confuse the uninformed of this trick.
At this moment, when a task seems to be first loaded, it immediately throws away the decorators you give it, and just generates a new instance of itself.
In your cog's `__init__`, once you do `self.my_task.start()`, the Loop is remade when it gets to `self.my_task` before executing the `start` function. The original Loop that the cog starts with is where the decorated values are. This fixes that.
This allows for easier "mock" context objects, for those who use
converters as utility functions outside of commands, and it's more
straightforward with the rest of the file.
Steve CandRapptz
