Replace multiprocessing usage in test fixtures with subprocess

[matrss]

Some advantages would be:

• no longer a necessity to use the "fork" method, which should allow the tests to run on windows as well
• no potential for an unclean server start due to the "fork" method, the server processes would start in their own new python interpreter
• due to the better separation it would become possible to e.g. start both an mscolab server with and without basic auth, enabling us to test different server configuration more effectively (right now the basic auth case can only be run separately)
• it would become possible to test with different WSGI servers, if we want that

[Myrausman]

Could you assign this issue to me?

[Myrausman]

are these only changes I must do, or are there any more requirements ?

def _running_eventlet_server(app):
    """Context manager that starts the app in an eventlet server and returns its URL."""
    scheme = "http"
    host = "127.0.0.1"
    socket = eventlet.listen((host, 0))
    port = socket.getsockname()[1]
    url = f"{scheme}://{host}:{port}"
    app.config['URL'] = url
    start_method = multiprocessing.get_start_method()
    if start_method != "fork":
        pytest.skip("requires the multiprocessing start_method 'fork', which is unavailable on this system")
    args = ["python", "-m", "eventlet.wsgi.server"]
    process = subprocess.Popen(args, stdout=subprocess.PIPE, stderr=subprocess.PIPE)
    try:
        process.start()
        while not is_url_response_ok(urllib.parse.urljoin(url, "index")):
            time.sleep(0.5)
        yield url
    finally:
        process.kill()
        process.communicate()
        process.close()

[matrss]

No, I think this should effectively start python mslib/mscolab/server.py start or its mswms counterpart using subprocess, depending on the fixture. This would also require a new approach to get the assigned port from the subprocess (or maybe a listening socket can be opened beforehand and its port can be re-used for the subprocess, not sure yet). This might also entail changes to tests (hopefully not many) and the configuration setup in the test suite might have to be adapted.

This is definitely a more complicated issue.