Python38 and refactor tests to use pytest-asyncio

[FlorianLudwig]

rebased version of njouanin/hbmqtt#226

depends on #17

[HerrMuellerluedenscheid]

I love where this is going! Thanks for addressing the tests @FlorianLudwig!

[HerrMuellerluedenscheid]

@FlorianLudwig do we want to squash commits? I could squash all of mine into a single python3 refactor I guess. But I don't want to do that without coordinating with you to avoid conflicts. If you consider squashing any of your feel free to do the same for mine. But after all it's just cosmetic. So, what do you think about squashing?

[FlorianLudwig]

tl;dr

pragmatic, i would just leave it as is.

squashing commits

It is on my TODO list to write my thoughts about squashing - a complicated topic indeed. So let me have a take on it :) Just to make a simple question a discussion about principles.

The git history is part of the work of a developer and not a backup. It should tell a story, each commit is one scene. Jumping to much between them and you lose your reader (that might be yourself in a few month, trying to understand why the code ended up the way it did or some psychopath).

Some rules of thumb:

• One commits should not never include unrelated changes

• Generally, try to keep commits small, making it easier to review each commit on it's own

• Automated changes to files that do not change the meaning (e.g. reformatting) must be a separate commit with the tools used clearly stated in the commit message

• Often before doing the change you actually want to do, there is some refactoring involved, in that case:

  Move refactoring into its own commit.
  A refactoring should keep the same end result of the software, while changing the code.
  Having a refactoring separated into a separate commit from other changes keeps them comprehensible and reviewable.