Describe the bug:
We're trying to bring up our vault with the https://github.com/1Password/vault-plugin-secrets-onepassword plugin fully configured and working. The plugin however does need configuration set at path op/config. The code at https://github.com/banzaicloud/bank-vaults/blob/50de449474cd3dd86a6d585c953608cbe3769944/internal/vault/secrets_engines.go#L229 and subsequently at https://github.com/banzaicloud/bank-vaults/blob/50de449474cd3dd86a6d585c953608cbe3769944/internal/vault/secrets_engines.go#L166 however only allows to use the /config name for a fixed list of engine types but not for the type plugin. This should be clearly configurable and not be a fixed list imho.

Expected behaviour:
In the vault crd, accept the following:

  externalConfig:
    plugins:
      - plugin_name: op-connect
        command: op-connect
        sha256: 7ce3e44c1a5f17e5f9b8dafd7a4c604b86ea862a69e5d2f12684cb0f136f5ba2
        type: secret
    secrets:
      - path: op
        type: plugin
        plugin_name: op-connect
        configuration:
          config:
          - op_connect_host: "http://{{ .Values.op_connector_service }}.svc.cluster.local:8080"
          - op_connect_token: {{ .Values.op_connect_token }}

Steps to reproduce the bug:
If you use the config as stated above the vault-configurer complains that it's missing a "name" parameter below the config which would automatically lead it to use that name as path for the config. The onepassword-connect plugin however does need it's config to be written to op/config and no subpath/name is needed.

I've managed to come up with this workaround as a hack:

  externalConfig:
    plugins:
      - plugin_name: op-connect
        command: op-connect
        sha256: 7ce3e44c1a5f17e5f9b8dafd7a4c604b86ea862a69e5d2f12684cb0f136f5ba2
        type: secret
    secrets:
      - path: op
        type: plugin
        plugin_name: op-connect
      - path: op
        type: kv # We need to fool the code in accepting no config path
        configuration:
          config:
          - op_connect_host: "http://{{ .Values.op_connector_service }}.svc.cluster.local:8080"
          - op_connect_token: {{ .Values.op_connect_token }}

This tricks the vault-configurer into setting up the plugin path as type plugin and later thanks to type: kv being in the allow list for /config paths it accepts the config to be written there.
I personally would recommend to have a flag below configuration: or at the same level indicating no need for a subpath.

Additional context:
I also had issues with the plugin not being executable which I was able to backtrace to the disable_mlock: true config option which the default vault chart always sets but the bank-vault crd needs that explicitly set. Using the same helm chart defaults as the original vault setup would be helpful I think.

Environment details:

• Kubernetes version (e.g. v1.10.2): v1.22.8
• Cloud-provider/provisioner (e.g. AKS, GKE, EKS, PKE etc): GKE
• bank-vaults version (e.g. 0.4.17): v1.15.5
• Install method (e.g. helm or static manifests): helm
• Logs from the misbehaving component (and any other relevant logs): {"level":"error","msg":"error configuring vault: error configuring secret engines for vault: error adding secrets engines: error finding sub config data name for secret engine: op/config","time":"2022-04-29T09:30:12Z"}
• Resource definition (possibly in YAML format) that caused the issue, without sensitive data: see above

/kind bug