Syncthing: enable reduced mover permissions

[JohnStrunk]

Describe the feature you'd like to have.
It should be possible to run the syncthing mover both with its current elevated permissions as well as with normal user permissions

What is the value to the end user? (why is it a priority?)
Running as a normal user is sufficient for typical replication scenarios, and it improves the security of the cluster by not running Pods w/ elevated permissions in the user's Namespace.

How will we know we have a good solution? (acceptance criteria)

• Mover uses the flag provided by Support a Namespace annotation indicating elevated privileges are ok for movers #365 to determine how the mover pod should be invoked
• Mover container image is able to run as both a normal user (UID != 0) and as UID==0
• "Elevated permission" mode preserves permissions/uid/gid, etc. to the extent possible given syncthing
• "Normal permission" provides best-effort preservation of metadata

Additional context

• Depends on Support a Namespace annotation indicating elevated privileges are ok for movers #365
• Special attention to the syncthing config volume may be necessary. In the case of OpenShift, the PVC will be automatically made accessible to the mover pod, but in vanilla kube, explicit setting of fsGroup or supplementalGroups may be necessary. (This will also need to be resolved for restic as a part of Restic: enable reduced mover permissions #367)

[JohnStrunk]

/assign @tesshuflower
Tesshu is working on Syncthing

[tesshuflower]

This was completed and in the 0.6.0 release.

/close

[openshift-ci]

@tesshuflower: Closing this issue.

In response to this:

This was completed and in the 0.6.0 release.

/close

Instructions for interacting with me using PR comments are available here. If you have questions or suggestions related to my behavior, please file an issue against the kubernetes/test-infra repository.