clarify a bit of obtuse logic

See merge request !12

blacken

See merge request !11

I was getting weird output from the script when trying to diagnose a
blocked dangerbot (e.g. #17 or #18). I couldn't figure out what was
going on and went to look at the code, then ended up staring at this
line for 2 minutes:

        # non-empty folder or regular file
        if len(listing) > 1 or not path.endswith("/"):

It stuck with me. I couldn't actually remember (let alone figure out)
what that was supposed to do. I was so confused I actually ended up
re-proving De Morgan's Laws:

https://en.wikipedia.org/wiki/De_Morgan%27s_laws

The gist of the change is that we change this:

        logging.info("sanitizing %s %s", folder, path)
        # non-empty folder or regular file
        if len(listing) > 1 or not path.endswith("/"):
            # [...] do everything

To this:

       if path.endswith("/") and len(listing) <= 1:
            logging.info("skipping empty folder: %s/%s", folder, path)
            return
       logging.info("sanitizing %s %s", folder, path)
       # [...] do everything

The diff looks huge because we reindent the entire "# [...] do
everything" block, but it's otherwise basically a noop, except we have
a better error message.

The output before:

anarcat@curie:dangerzone-webdav-processor(main)$ ./dangerzone-webdav-processor -l https://nc.torproject.net/remote.php/dav/files/dangerzone-bot/ -u dangerzone-bot -n  -v
authenticated with webdav https://nc.torproject.net/remote.php/dav/files/dangerzone-bot/
sanitizing CVs (4)/ Candidate 33/
sanitizing CVs (4)/ Candidate 35/

after:

anarcat@curie:dangerzone-webdav-processor(main)$ ./dangerzone-webdav-processor -l https://nc.torproject.net/remote.php/dav/files/dangerzone-bot/ -u dangerzone-bot -n  -v
authenticated with webdav https://nc.torproject.net/remote.php/dav/files/dangerzone-bot/
skipping empty folder: CVs (4)//Candidate 33/
skipping empty folder: CVs (4)//Candidate 35/

We do it in a rather convoluted way (ie. tox) but it will allow us to
hook more goodies later, e.g. mypy, unit tests, etc.

Previously if the remote safe directory wasn't fully created, the script
would crash and leave files in the remote processing directory

We have service docs that are way more extensive, meaningful and
relevant than keeping those historical details in the project's README
file.

Plus it would be silly to keep those things duplicated between the two
places...

Use os.path.join instead of string concatenation

See merge request !9

It seems like this was the result of a massive search and replace that
was a little too enthusiastic.

Any `docker run --tty` (which `-it` implies) crashes with:

    the input device is not a TTY

... when running as a systemd service. It seems like keeping
`-i` (which we expand to `--interactive` for clarity) keeps everything
normal (ie. we still see the container output).

Closes: #15

We need an extra control after argument passing to make sure it's
there when the options are not given though.

This is the proper place to this level of abstraction, i think.

This makes it possible to enable verbose without reloading systemd.

I'm not exactly sure we'll go that route, but it will make deployment
clearer.

Note that this involves renaming the main script, which makes the
directory listing a little more confusing and redundant, but it makes
the `setup.py` stuff easier (because we don't need to rename the
file).

The downside is that it doesn't look like a python module anymore,
which confuses some tools, but we can always add a symlink in the
source (like we do in undertime) to workaround that problem, in the
future.

Closes: #3

This hasn't actually been tested but, really, "how hard can this be?"

We're pretty good at avoiding race conditions (by moving stuff to
`dangerzone/processing`, mostly) but we definitely should avoid two
processors in parallel. Thankfully, it seems that systemd takes care
of this for us and will not run two services in parallel.

Obviously, the user can still shoot themselves in the foot and run
another processor in parallel, but that's when our race avoidance
stuff should save us.

Closes: #1

The `upload_sync()` function actually wipes the remote directory (or,
more precisely, removes files not present locally), so we actually
need to specify which component we need to upload, otherwise other
sanitized folders will get destroyed.

Closes: #7

handle already existing remote files on move

Closes #4

See merge request !3

hide all dangerous folders under a single dangerzone/ folder

Closes #4

See merge request !2

For some reason, we have files in the processing folder that are
already present before moving. Skip those files instead of crashing
with:

webdav3.exceptions.ResponseErrorCode: Request to https://nc.torproject.net/remote.php/dav/files/dangerzone-bot/CVS/dangerzone-processing/2/ failed with code 412 and message: b'<?xml version="1.0" encoding="utf-8"?>\n<d:error xmlns:d="DAV:" xmlns:s="http://sabredav.org/ns">\n  <s:exception>Sabre\\DAV\\Exception\\PreconditionFailed</s:exception>\n  <s:message>The destination node already exists, and the overwrite header is set to false</s:message>\n  <s:header>Overwrite</s:header>\n</d:error>\n'

Right now we have `dangerzene-processed/`, `dangerzone-rejected/`,
`dangerzone-processing/`... that's noisy, at best, and dangerous, at
worst: at least one user thought that `dangerzone-processed` was where
processed (so: safe) files ended up.

Just have `dangerzone/` and `safe/` folders at the toplevel, with the
`processed/`, `rejected/`, `processing/` stuff inside `dangerzone/`.

Closes: #4

fix incorrect SPECIAL_FOLDERS path check

Closes #8

See merge request !1

remove trailing slash from SPECIAL_FOLDERS entry
create function to normalize paths before checking to make things easier for
caller
closes #8

Not sure why that worked, but this can't hurt.

See: #6

Partly based on notes from
team#40256