Lock a file around the NVT sync

[mattmundell]

This is required because it is now possible to start a sync outside the gvmd main process, with --rebuild.

Also, the lock file provides a way to check if the sync is running.

Checklist:

• Tests
• CHANGELOG Entry

[timopollmeier]

Shouldn't the lock files be released after the update is done? At least it would be be more consistent
with the other use of lockfile_lock_nb and closing the lock fd at the end of the SCAP and CERT syncs.

Also, the other sync lockfiles use "gvm-sync-..." instead of "gvm-syncing-...", but I'm not sure if those or the new NVT one should be changed...

[mattmundell]

Shouldn't the lock files be released after the update is done? At least it would be be more consistent
with the other use of lockfile_lock_nb and closing the lock fd at the end of the SCAP and CERT syncs.

Also, the other sync lockfiles use "gvm-sync-..." instead of "gvm-syncing-...", but I'm not sure if those or the new NVT one should be changed...

I've tried to be consistent with the other uses of the lockfile_* functions and not with the SecInfo locking.

The SecInfo locking in gvm_migrate_secinfo should be changed to use lockfile_*. Not sure why it is done by hand. The other lockfile cases are all using "gvm-syncing..." style, like "gvm-checking", "gvm-migrating" (except "gvm-create-functions"). So they could all be changed to the "ing" style, but not serious for me.

And the SecInfo locking in sync_secinfo/scap/cert should also use lockfile_*. I get that unlike the NVT sync this doing an unlock, but some other cases of lockfile_* do not unlock because it happens automatically at the end of the process (eg gvm-migrating). Don't mind adding the unlock if it bothers you though.