Fix PostgreSQL permissions and data schema, and relevant docs

[craddm]

✅ Checklist

• You have given your pull request a meaningful title (e.g. Enable foobar integration rather than 515 foobar).
• You are targeting the appropriate branch. If you're not certain which one this is, it should be develop.
• Your branch is up-to-date with the target branch (it probably was when you started, but it may have changed since then).
• You have marked this pull request as a draft and added '[WIP]' to the title if needed (if you're not yet ready to merge).
• You have formatted your code using appropriate automated tools (for example ./tests/AutoFormat_Powershell.ps1 -TargetPath <path to file or directory> for Powershell).

⤴️ Summary

Moves the script that ensures users have appropriate roles for modifying certain database tables to the correct directory, and corrects the mustache file that adds this script to the server. Previously, the script was not present on the server. Thus users were not given the right permissions and no data schema was created.

Changes the database trigger to avoid using pg_has_role. For superusers, pg_has_role reports that they have every possible user role on the server, irrespective of what other roles they are actually assigned.

Adds a cron job that runs every 10 minutes, 1 minute after the LDAP users are updated, to trigger an update of user roles.

Updates docs for system managers regarding the intended use of the security groups on the DC and their impact on database access rights.

🌂 Related issues

Relates to #1438 and #1392

🔬 Tests

Deployed a new PostgreSQL database, created and modified a table in the data schema using a user in the Data Administrators security group and confirmed that a Research Users user could only read, not modify the table.

Checked that user permissions are correctly updated on the PostgreSQL database. The permissions now update appropriately every 10 minutes, including removing a user from the Sys Admins group.

[JimMadge]

Should it be closes #1438 and #1392?

[craddm]

That's something I wanted to discuss.

#1438 is partly covered by this, but this doesn't address point 2 of #1438 - without being in Research Users group, sys admins and data administrators can't get to the database to modify anything. If we are fine with that (and the docs now spell out that they need to be research users to be able to login to the SRD), then this closes #1438

#1392 is slightly more about telling users how to use the databases. I've just added links to tutorials for MSSQL and PostgreSQL that hopefully suffice.