Should `hackage-server init` be creating a lockfile?

This arises using hackage-server 0.5.1, as built from the `hackage-deployment-2020-05-03` tag (commit d43012169a11a0bb2229ef207e607b6c3d83b99c) on Ubuntu 18.04. I used a slight variation of the provided [Dockerfile][dockerfile]

[dockerfile]: https://raw.githubusercontent.com/haskell/hackage-server/hackage-deployment-2020-05-03/Dockerfile

(The exact Dockerfile used is given here.)

```
FROM ubuntu:18.04@sha256:0fedbd5bd9fb72089c7bbca476949e10593cebed9b1fb9edf5b79dbbacddd7d6 \
as build

ARG GHC_VERSION=8.2.2 \
CABAL_VERSION=3.0

RUN \
apt-get update \
&& apt-get install -y --no-install-recommends \
software-properties-common \
&& DEBIAN_FRONTEND=noninteractive apt-get install -y --no-install-recommends \
git \
libicu-dev \
libssl-dev \
unzip \
zlib1g-dev \
&& apt-add-repository ppa:hvr/ghc \
&& apt-get update \
&& DEBIAN_FRONTEND=noninteractive apt-get install -y --no-install-recommends \
cabal-install-${CABAL_VERSION} \
ghc-${GHC_VERSION} \
# Remove unnecessary stuff
&& apt-get autoclean \
&& apt-get clean -y \
&& apt-get --purge -y autoremove \
&& rm -rf /var/lib/apt/lists/* /tmp/* /var/tmp/*

ENV PATH /opt/ghc/bin:$PATH

RUN mkdir /build
WORKDIR /build

ARG HACKAGE_VERSION=hackage-deployment-2020-05-03

RUN \
cabal v2-update \
&& git clone https://github.com/haskell/hackage-server.git . \
&& git checkout ${HACKAGE_VERSION} \
&& cabal v2-build --only-dependencies \
&& cabal v2-install --install-method=copy --constraint='text < 2.0' hackage-repo-tool

ENV PATH /root/.cabal/bin:$PATH

RUN \
hackage-repo-tool create-keys --keys keys \
&& cp keys/timestamp/*.private datafiles/TUF/timestamp.private \
&& cp keys/snapshot/*.private datafiles/TUF/snapshot.private \
&& hackage-repo-tool create-root --keys keys -o datafiles/TUF/root.json \
&& hackage-repo-tool create-mirrors --keys keys -o datafiles/TUF/mirrors.json \
&& cabal v2-build \
&& cabal v2-install --install-method=copy

###
# server

FROM ubuntu:18.04@sha256:0fedbd5bd9fb72089c7bbca476949e10593cebed9b1fb9edf5b79dbbacddd7d6

SHELL ["/bin/bash", "-c"]

ARG CABAL_DIR=/root/.cabal
ENV PATH ${CABAL_DIR}/bin:$PATH
COPY --from=build ${CABAL_DIR}/bin ${CABAL_DIR}/bin

RUN \
apt-get update \
&& DEBIAN_FRONTEND=noninteractive apt-get install -y --no-install-recommends \
ca-certificates \
curl \
libicu60 \
libssl1.1 \
netbase \
zlib1g \
# Remove unnecessary stuff
&& apt-get autoclean \
&& apt-get clean -y \
&& apt-get --purge -y autoremove \
&& rm -rf /var/lib/apt/lists/* /tmp/* /var/tmp/*#

# setup server runtime environment

RUN mkdir /runtime
WORKDIR /runtime

COPY --from=build /build/datafiles /runtime/datafiles

RUN \
hackage-server init --static-dir=datafiles
```

Running `hackage-server init` command results in the following output:

```
$ hackage-server init --static-dir=datafiles
hackage-server: Creating initial state...
finalising data for feature users
finalising data for feature core
finalising data for feature security
hackage-server: Using default administrator account (user admin, passwd admin)
hackage-server: Done
```

On my system at least, this seems to reliably create the file `state/db/Tags/Alias/open.lock` - should this be happening? Usually, I'd expect the existence of a lockfile to indicate there's a *running* instance of `hackage-server`, which obviously isn't the case here.

The existence of the lockfile seems to sporadically result in errors when `hackage-server run` is executed. Sometimes (but not always), running `hackage-server run --static-dir=datafiles --base-uri=http://localhost:8080/` will result in an error like the following:

```
state/db/Tags/Alias/open.lock: Locked by 1: resource busy
```

It seems like `hackage-server init` shouldn't be creating a lockfile, but perhaps this is intended behaviour. If it is, perhaps it would be worth documenting what the purpose of the lockfile is.