DSID checking in commit script and CI

This MR introduces two changes:

• checking of DSID range in commit_new_dsid.sh and in CI
• suggestion of DSID range to use

Checking of DSIDs

When commit_new_dsid.sh is run it will automatically loop over all jO that are added (specified with the -d flag) and make sure that they are in the correct DSID range, as discussed in #29 (closed).

Example (correct DSID range):

Example (wrong DSID range):

The DSID range checking is done via the check_jo_consistency.py script, so one also performs all the naming checks at the same time.

Typically one would first run with -n so one is supposed to rename the directories according to what the script suggest and then rerun the scripts with the correct DSIDs and eventually commit.

CI

The CI check is incorporated in the check_jo_consistency job, i.e. after this MR is merged one will not only check the jO for their naming but also make sure that they are in a directory in the correct DSID range.

Since this job is not allowed to fail we won't be accepting jOs if they don't live in the correct DSID range.

Example:

How the suggestion mechanism works

When doing the dry-run of the commit script the script will:

1. loop over all DSIDs in the commit
2. identify the jO in each DSID directory and extract the first generator
3. query all the heads in origin, find the min and max allowed DSID for the generator determined in (2) and return the minimum free DSID

Important

• since the minimum free DSID is returned if there are "holes" in a DSID range, the suggested range will try to cover them, e.g. if 700000,700002 are occupied and we ask to commit 3 new Sherpa jO the script will suggest 700001,700003,700004. As time goes by, this should happen less often if people stick to the suggestion of the script
• if a DSID to be committed is already in the correct DSID range, there is no ERROR thrown. In the above example, if 700000,700002 are occupied and we put a new Sherpa DSID in 799999 the script will not complain.

Closes #29 (closed)