grass.app: Move lock to mapset subcommand

[wenzeslaus]

The lock and unlock subcommands are operating on a mapset and are low-level (they specifically just lock and unlock and don't do anything with any session). So, this is moving them under a new top-level subcommand mapset.

With the lock subcommands being accessible outside of GRASS through CLI without a Python API or a GRASS tools (with or without #6442), other applications which can call subprocesses (such as QGIS) can use GRASS locking when accessing GRASS mapsets.

This is using the new structure in the cli.py file with parser definitions having their own functions (minimizing name conflicts between parses and keeping the main function short), but additionally the interface and execution code are placed together because they would be changed at the same time.

Waiting for #6462: Additionally, for symmetry with project create, this adds a new mapset create subcommand which is used in the test. The creation uses the semi-internal function grass.grassdb.create.create_mapset. The function parameters were adjusted to allow for a single path being provided (which was already supported through path resolution function).

Examples

Assuming #6442 in the examples to simply the commands, but setting up PYTHONPATH and using python -m grass.app would work too.

grass mapset lock

$ grass project create /tmp/project_1
$ grass mapset create /tmp/project_1/work_2
$ grass mapset lock /tmp/project_1/work_2
$ grass mapset lock /tmp/project_1/work_2
Mapset <.../project_1/work_2> locked (attempt 1), but will retry in 1.00 seconds...
Mapset <.../project_1/work_2> locked (attempt 2), but will retry in 2.00 seconds...
Mapset <.../project_1/work_2> locked (attempt 3), but will retry in 4.00 seconds...
Mapset <.../project_1/work_2> locked (attempt 4), but will retry in 8.00 seconds...
Mapset <.../project_1/work_2> locked (attempt 5), but will retry in 15.00 seconds...
Selected mapset is currently being used by another GRASS session. File /tmp/project_1/work_2/.gislock owned by vpetras found. Concurrent access to a mapset is not allowed. However, you can either use another mapset within the same project or remove the lock if you are sure that no other session is active.
On the command line, you can force GRASS to start by using the -f flag.
In Python, you can start a session with force_unlock=True.
Make sure you have sufficient access permissions to remove the lock file. You may want to use a process manager to check that no other process is using the mapset.
$ grass mapset unlock /tmp/project_1/work_2

grass mapset create (with grass project create)

$ grass project create /tmp/project_2 --crs EPSG:3358
$ grass run --project /tmp/project_2 g.proj -p format=json | jq
{
  "name": "NAD83(HARN) / North Carolina",
  "datum": "nad83harn",
  "ellps": "grs80",
  "proj": "lcc",
  "lat_0": "33.75",
  "lon_0": "-79",
  "lat_1": "36.1666666666667",
  "lat_2": "34.3333333333333",
  "x_0": "609601.22",
  "y_0": "0",
  "no_defs": "defined",
  "srid": "EPSG:3358",
  "unit": "meter",
  "units": "meters",
  "meters": "1"
}
$ grass mapset create /tmp/project_2/work_1
$ grass run --project /tmp/project_2/work_1 g.mapset -p format=json | jq
{
  "project": "project_2",
  "mapset": "work_1"
}

[wenzeslaus]

This is now a draft because I moves some of the pieces to separate PRs, but this now depends on these PRs and it will also need little more cleanup.