init: Add retries and timeout to mapset locking

[wenzeslaus]

This change introduces a timeout parameter in CLI which is enabled by default and makes GRASS wait if the mapset is locked.

Additionally, this adds timeout parameter also to the Python API, so this keeps feature parity between the two (with locking and force lock removal already in place since #5591). The automatic tests are using the Python API, but they are limited as they don't use multiple threads or processes.

Locked mapset example in CLI:

$ grass ~/grassdata/nc_spm_08_grass7/user1/
Starting GRASS GIS...
Mapset <.../nc_spm_08_grass7/user1> locked (attempt 1), but will retry in 1.00 seconds...
Mapset <.../nc_spm_08_grass7/user1> locked (attempt 2), but will retry in 2.00 seconds...
Mapset <.../nc_spm_08_grass7/user1> locked (attempt 3), but will retry in 4.00 seconds...

Lock in Python (also works as a context manager):

import grass.script as gs
s = gs.setup.init("~/grassdata/nc_spm_08_grass7/user1/", lock=True, timeout=0)
s.finish()

This also introduces new subcommands to the experimental execution of the grass.app with CLI API using python -m grass.app from #5590. Specifically, lock and unlock subcommands are now available and can be used for testing (compensating for the limited automatic tests), fixing lock situations, and by external applications which need to persistently lock mapset without using the Python API directly. Subcommands are added to the first level, but could eventually be under a project or mapset subcommand.

Example lock-unlock (path to Python packages needs to be setup, don't ask me why LD_LIBRARY_PATH does not need to be setup - but it is needed for test of the Python API):

export PYTHONPATH="$(.../bin.x86_64-pc-linux-gnu/grass --config python-path)"
python -m grass.app lock ~/grassdata/nc_spm_08_grass7/user1/
python -m grass.app unlock ~/grassdata/nc_spm_08_grass7/user1/

Notably, the locking is disabled on Windows, so test is disabled for Windows.

[wenzeslaus]

I need to fix the tests...there is no locking on Windows. Otherwise the tests pass.

[echoix]

Isn't this starting to be three PRs at once? At least for the cli changes, that are great by themselves. (I already explored similar changes like two years ago when starting to work on modernizing gunittest, syncing with upstream unittest, but wasn't completed as no way to fully validate if it there would be impacts on tests on all our platforms, as that the tests were not all running or would allow failures on some platforms). But the __main__.py approach is correct!

[echoix]

And if you are up to fixing some tests, maybe update the branch that is 108 commits behind, I’ve made some progress on this part recently. And more to come.

[wenzeslaus]

I can split that, adding the locking to init without a timeout. The reason I did only one is that init and CLI should have feature parity and the __main__.py CLI was just a good way of testing the changes.

[echoix]

From digging the history quite often, I know that following renames+changes are quite hard. The CLI main part could go right through, and then add on the options?

[wenzeslaus]

From digging the history quite often, I know that following renames+changes are quite hard. The CLI main part could go right through, and then add on the options?

This PR does not have a rename, no?

[echoix]

Indeed, I looked at the commits of yesterday, and thought that 0a2887f was moving code around from __main__.py to cli.py. While for the PR, both are new files.

[wenzeslaus]

I have now WIP to introduce the internal CLI with just simple help functionality and I'll later split also the Python locking addition to a separate PR.

[wenzeslaus]

This is now ready for review again. It includes changes from #5590 (subcommands) and #5591 (locking in Python API).