Hi all!

I'm digging more and more into the internals of Emacs these days, and
while tracing input lag performance i noticed that we don't respect the
create-lockfiles option, at least not fully.

The documentation states:
```
If the option `create-lockfiles' is nil, this does nothing.
```
However, the nothing is postponed until later, inside the lock_file
function. This means we won't cretae the lockfile, but we will get the
truename-buffer, verify visited file, etc, on my system amounting to
some time spent which I thought I opted out of.

Along with a patch that fixes this behavior I've added 4 screenshots of
graphs taken through intel_pt tracing on trigger of self-insert inside a
c file.

to reproduce what I do, from inside my emacs source code folder:

```
;; normal emacs built from source a couple of days ago
emacs -Q +644 src/filelock.c
emacs -Q -eval "(setq create-lockfiles nil)" +644 src/filelock.c

;; emacs with the provided patch
./src/emacs -Q +644 src/filelock.c
./src/emacs -Q -eval "(setq create-lockfiles nil)" +644 src/filelock.c
```

The first two screenshots show the current behavior without this patch,
where you can see that we still do some lock-file related computing even
though the setting is off. The last two show that we don't do it at all,
while preserving the vanilla operation when create-lockfiles = t.

The lock file related code can take up to a millisecond on my system,
but is usually in the range of 200-300 microseconds.

It seems there was some cleanup/changes around this behavior which i
believe caused this as a regression, from around 3 years ago. I _think_
this commit: 9ce6541ac9710933beca7f9944087fe4849d5ae9

Theo