Use PySNMP >6 asyncio API

[Emantor]

Description
Update pysnmp and it's users to use the new async API, this should fix CI and also ensures we can properly use pysnmp in the future.
Pushed additional fixes for no longer required pylint disables.

Checklist

• PR has been tested

Fixes #1493
Closes #1456

[Bastian-Krause]

Client code does the same, but only in start_session() when no loop is provided otherwise (and stashes the loop for later use).

How would other code retrieve the newly created event loop from here?

I think this must rely on an existing event loop, similar to EthernetPortManager:

labgrid/labgrid/resource/ethernetport.py

Line 251 in 6b54121

self.loop = asyncio.get_event_loop()

[Emantor]

But get_event_loop is deprecated, so I chose not to use this.
I also think that get_running_loop almost always returns a runtime error here.

[Bastian-Krause]

No, get_event_loop() is not deprecated per se: only if there is no current event loop. That's why I think we should simply expect a loop here. If there is none, that's an error that needs to be fixed outside of labgrid.

[Emantor]

Using labgrid as a library means that there is not necessarily an available loop and we need to support this (which is exactly the case where there is no loop).

[Emantor]

Testing this inside of labgrid client reveals that get_running_loop does not find the running client event loop and instead no loop is found and another is created for SNMP.

[Bastian-Krause]

Using labgrid as a library means that there is not necessarily an available loop and we need to support this (which is exactly the case where there is no loop).

I disagree. There are certain "entry points" into labgrid where a loop can be passed or labgrid tries to find one or sets a new one up as a fallback. Exporter, coordinator and client are these "entry points". Client and libraries typically use labgrid.remote.client.start_session() to start a session. So that makes sure there is a loop.

For all other cases, code that uses labgrid as a library needs to make sure a loop exists. Maybe that needs to be documented better.

Using get_event_loop() in EthernetPortManager was an active decision. Using that makes sure there is an event loop. Otherwise you get a warning (and a new event loop) or an error, depending on the Python version.

Testing this inside of labgrid client reveals that get_running_loop does not find the running client event loop and instead no loop is found and another is created for SNMP.

That's because get_running_loop() does not work in sync contexts and there is no other way to achieve that.

[Emantor]

I guess this is fine for the SNMP switch handling, but isn't the correct requirement for the simple power backend handling we had beforehand. So how do we proceed with this? Requiring an event loop for sync library usage is not really feasible.

[Bastian-Krause]

How does the simple power backend handling work without a session?

[Emantor]

How does the simple power backend handling work without a session?

What do you mean? You can totally describe all of the NetworkPowerPorts inside of the YAML configuration and not use a RemotePlace to retrieve the resources.

[Bastian-Krause]

Yes, I see.

See commit messages of da95c44, 0e1e4fb and 606af35 for context.

What about calling labgrid.remote.client.ensure_event_loop() whenever we need an event loop? That would restore the original behavior of using labgrid as a library without a coordinator session.

We could add a function that allows library users to pass their own event loop into labgrid (stashing it) for use cases without labgrid.remote.client.start_session() (which already allows passing an external loop).