os-sftp-backup - Version: 1.1_2 - extend default hardcoded upload file permissions from 0600 to 0666

Important notices
Before you add a new report, we ask you kindly to acknowledge the following:

• I have read the contributing guide lines at https://github.com/opnsense/plugins/blob/master/CONTRIBUTING.md
• I have searched the existing issues, open and closed, and I'm convinced that mine is new.
• The title contains the plugin to which this issue belongs

Describe the bug
A clear and concise description of what the bug is, including last known working version (if any).

Change the following line managing the permissions on the uploaded file in the Sftp.php file and set the permissions from 0600 to 0666:

File::file_put_contents($tmpfilename, $confdata, 0600);

Tip: to validate your setup was working with the previous version, use opnsense-revert (https://docs.opnsense.org/manual/opnsense_tools.html#opnsense-revert)

To Reproduce
Steps to reproduce the behavior:
Simply click on the button "Setup/Test sftp" under:
System --> Configuration --> Backup --> sftp

Expected behavior
The uploaded file must provide rw-rw-rw- (666) permissions, and not rw------- (600) because it makes it unusable to any other user. The minimum acceptable permissions would be 0660, but since they can be umasked on the SFTP server side, 0666 should be chosen.

Screenshots
Not needed.

Relevant log files
Not needed.

Additional context
I actually use a FreeBSD server on which I have chrooted the "opnsense" user uploading the configuration backup files with your os-sftp-backup plugin. The default permissions (hardcoded) are 0600, thus giving exclusively rw to the owner (i.e., uploader) of the backup files, which is excessively restricting, since only the owner can access the files afterwards. In my case the, the SFTP user "opnsense" is chrooted in a directory on the FreeBSD server. I would strongly suggest to change the default permissions to 0666 (we can then umask them with -u 0027 in the sshd_config file: Subsystem sftp internal-sftp -u 027 ; ForceCommand internal-sftp -u 027), so that the "group" can have full access to the backup file to manage.

Currently, I am using a cron job applying a chmod 0660 script on the directory getting the uploaded SFTP files! Another option that is not acceptable for security reasons is login in as a real user, not chrooted. Both solutions are not elegant. All other examples of SFTP backups (e.g., printers, scanners, android phone uploads, etc...) are all using 0666 permissions (not configurable on the client, but easily maskable on the server).

Environment
Limited to the plugin: os-sftp-backup (in this case in the following version, but not limited to it: Version: 1.1_2)