Add polling and test it

[Flix6x]

I implemented basic polling. Follow-ups:

• The test depends on unmerged aioresponses functionality -> see feat: integer repeat pnuckowski/aioresponses#237.
• Move to a more elegant step function (increasing steps) -> see Issue Increase the polling interval with each re-try #3.
• There is no HTTP status code to convey "please retry later", but there is a dedicated header that the client could listen to instead: Retry-After. I'd rather move to having FlexMeasures server use this, instead of moving the client's polling logic to the get_schedule method. I kind of like that the polling logic is implemented on all requests to FlexMeasures whose responses indicate to retry the request later. -> see Use Retry-After HTTP header for scheduling in progress flexmeasures#645

[victorgarcia98]

Thanks @Flix6x!

I have only minor change requests and a couple of potential new features:

• Using the same code to allow to retry the request in case of failiure (up to a maximum number of times.
• Limiting the polling time. It shouldn't occur, but if a Job becomes "Zombie" and it's not finishing, we just disregard the request. For instance, the polling time limit could be set to a few hours.

[nhoening]

Good stuff. I have some ideas about the retrying intervals and, as always, naming.

[victorgarcia98]

Thanks @Flix6x!

I've only small suggestions.

Other than that, I think we could add some validators to the FlexmeasuresClient class, maybe not for this PR:

• lenght of emai, password and host
• force scheme to be http or https
• check if polling_timeout > request_timeout > 0

Somewhat unrelated to this PR, but now that is early and we don't have too much depending on this, I was thinking that we might consider refactoring the class name from FlexmeasuresClient to FlexMeasuresClient.

[Flix6x]

Closing this PR, as its contents have been incorporated into #7.