sit.cephfs: Add share configured with `vfs_ceph_new`(non-mgr)

[anoopcs9]

depends on #117

[spuiuk]

I think instead of adding a new variable, we should just add to the list of variants. "vfs_new"?

[anoopcs9]

I think instead of adding a new variable, we should just add to the list of variants. "vfs_new"?

There are multiple aspects to be considered here:

• As of now smb mgr module based configuration is based on backend=cephfs.mgr.vfs which indicates the need for ceph native method using the second part of the backend specification. This looked more relatable and meaningful.
• Going forward we may include another configuration using proxy. If go with _vfsnew we end up with _vfs_newproxy. I think _cephfs.vfs.newproxy will be more sensible. Of course this will end up as _cephfs.mgr.vfs_newproxy for the other case.
• Sooner or later we would have only two: cephfs and cephfs.mgr. All other variations are supposed to be clubbed together. Till then it might be easier to put anything extra(new vfs module, proxy requirement) other than the setup method choices separately to avoid any complication in intelligently deriving everything from a single variable.

Let me know if you had something else in your mind.

[anoopcs9]

I think instead of adding a new variable, we should just add to the list of variants. "vfs_new"?

I think I'll reverse the order here to first make the change to group possible shares(starting with cephfs) and then rework this PR to add another share(using _vfs_cephnew) on top of it.

[spuiuk]

I think the code is far too complex now with a number of if conditions causing it to split into multiple code paths. This change adds another such conditions. I think it would be far easier to go straight to grouping now.

[dpulls[bot]]

:warning: Dpulls not installed on repository ceph/ceph. Checkout our quickstart for how to install.

[anoopcs9]

/retest centos-ci/xfs

[dpulls[bot]]

:tada: All dependencies have been resolved !