Refactor the postgresql invite module

[vxgmichel]

The components.postgresql.invite module has not yet been migrated to the new code layout where each command gets its own dedicated module with the corresponding queries inside.

During this migration, the locking approach needs to be reconsidered.

First, the advisory lock on invitation creation can be removed as described in #9300.
Then, the common topic read lock might not need to be taken as explained by this comment in _q_retrieve_shamir_recovery_setup:

-- We do not lock the shamir topic in read here.
-- This is because topic locking is usually reserved to operations that needs to accept or reject
-- consistent timestamped data from the users, such as certificates or vlobs. Here, only the invitations
-- gets updated, which do not have to remain consistent with other timestamped data.
-- Less lock means less ways to mess up the ordering and create a hard-to-debug deadlock,
-- so we simply accept that our checks might be slightly outdated when the invitation is written.

For the same reason that we do not lock the shamir topic in read here, we might also be able to skip the locking of the common topic.

Careful still: locking the common topic should not be skipped if we perform several checks in the same transaction while making assumptions about those checks based on the results from the previous ones. Skipping the locking should only be done if the checks are independent.

However, we should keep the invitation lock which prevent concurrent update of a given invitation.