Add check_reserved_lock method.

[bkoropoff]

sqlite will call this operation when a database is being concurrently modified, so it must be present and implemented to avoid a null deref or incorrect locking semantics.

[carlsverre]

This is super interesting - I haven't yet encountered this vfs call from SQLite. Are you sure SQLite calls this method if it's null? Do you have a repro that I can use to test this?

In general, this PR looks fine - although I'm hesitant to default this method to return false as that clearly signals to SQLite that "this process is never holding any locks".

[carlsverre]

Ok, after doing a bit more research, it appears this is triggered (afaict) only when we take a shared lock and discover that a journal file exists. I haven't hit this problem because I keep all journals in memory, which is a Graft property.

Cool, this seems solid for certain kinds of VFS's - mainly ones that allow for durable journals.

As for the function returning false by default... That feels like a footgun. I think I'll just make it a required method so that folks reason about it.

[carlsverre]

Actually, on second thought, the other lock methods are transparent noops already, so the footgun already exists. Will keep your version.

Thanks for the contribution!

[bkoropoff]

I managed to hit this throwing parallel writers at a VFS backend that is ultimately filesystem-backed. I did find the lock methods being defaulted somewhat concerning. Making them mandatory might be a good change for the next incompatible version bump.

[carlsverre]

Thank you for the additional context! I was super concerned that I hadn't hit it yet until I learned when SQLite uses it.

And yeah, I should probably make them mandatory. Appreciate the feedback! Also if you ever want to talk about what you're working on I'd love to hear it! I hang out in the orbitinghail discord here: https://discord.gg/etFk2N9nzC