SFTP: Allow to configure users via a secret

[paoloyx]

What this PR wants to bring

As title, I wonder if could be useful to configure the chart via a K8s secret that uses the same exact configuration as the one provided by .Values.sftp.users. If present, the secret would take the precedence.

For example, instead of doing this:

---
# Default values for sftp.
# This is a YAML-formatted file.
# Declare variables to be passed into your templates.
[...]
sftp:
  # Array based configuration of users 
  users:
    - name: demo
      pass: demo
      # -- password is encrypted ([doc](https://github.com/atmoz/sftp/blob/ffeb104beec76cc622abda34ee2132c790b5559c/README.md#encrypted-password))
      passEncrypted: false
      uid: ""
      gid: ""
      dirs:
        - upload
      # -- public user keys ([doc](https://github.com/atmoz/sftp/blob/ffeb104beec76cc622abda34ee2132c790b5559c/README.md#logging-in-with-ssh-keys))
      pubKeys: []

We could alternatively get users' configuration from a my-users-config pre-existing secret in the following way:

# Default values for sftp.
# This is a YAML-formatted file.
# Declare variables to be passed into your templates.
[...]
sftp:
    # -- Reference to and existing secret that provides users' configuration.
  # If present takes precedence over `.Values.sftp.users` configuration,
  # whose schema is expected to use within a `users.conf` key 
  usersSecret: "my-users-config"

    # Set as empty array but could be left as it is with its default values
  users: {}

The my-users-config secret would be like this (please notice that I'm reading from a users.conf key):

➜  kubectl get secret my-users-config -o jsonpath='{.data.users\.conf}' | base64 -d
- name: demo
  pass: demo
  # -- password is encrypted ([doc](https://github.com/atmoz/sftp/blob/ffeb104beec76cc622abda34ee2132c790b5559c/README.md#encrypted-password))
  passEncrypted: false
  uid: ""
  gid: ""
  dirs:
    - upload
  # -- public user keys ([doc](https://github.com/atmoz/sftp/blob/ffeb104beec76cc622abda34ee2132c790b5559c/README.md#logging-in-with-ssh-keys))
      pubKeys: []

Please note

The code can be refactored as you may feel best to do. Additionally I have not updated the tests, but it won't be a problem to manage them if necessary :)

[sj14]

Hi paoloyx, I like the idea that the users can provide their own secret with the required data.
Please see if you can update the tests. I would love to have a new test case for it, but I think it will just fail, as the secret can't be found, but not quite sure how this case will behave, maybe give it a try to see if it will generate something valuable.

[paoloyx]

@sj14
The config-users.yaml has been changed in structure, while preserving functionality, but its sha256sum has changed accordingly, so I think that we must update it.
This is true for every test output, does it sound good for you?

[sj14]

Yeah, that's expected.