[BUG] Bugfix for #62651 broke existing functionality for ext_pillar vault KV v2

[vshalchian]

Description

Before the bugfix for #62651 the behavior of ext_pillar for vault KV v2 was having the data under "data" key. Since that was the case I had all my code set up pointing to pillar['data'] and looked at it as a feature.
After the fix in #62653 , the behavior is changed and pillars are not under 'data' key anymore which causes my salt state code to be broken and I cannot upgrade to newer versions unless I do a massive refactoring on my codebase.

My suggestion is adding a configuration directive to enable previous behavior of having the 'data' key back.

Setup
[...]
ext_pillar:

• vault: path=salt/pillar/path
  [...]

Steps to Reproduce the behavior
salt 'minion1' pillar.items
centos51:
----------
secrets:
----------
key1:
----------
key2:
----------

Expected behavior
salt 'minion1' pillar.items
centos51:
----------
data:
----------
secrets:
----------
key1:
----------
key2:
----------

Screenshots
If applicable, add screenshots to help explain your problem.

Versions Report

salt --versions-report

(Provided by running salt --versions-report. Please also mention any differences in master/minion versions.)

PASTE HERE

Additional context
Add any other context about the problem here.

[lkubb]

This feature already exists, see the nesting_key parameter of the Vault pillar.

salt/salt/pillar/vault.py

Lines 27 to 34 in 97e9395

	If you want to nest results under a nesting_key name use the following format:
	.. code-block:: yaml
	ext_pillar:
	- vault:
	conf: path=secret/salt
	nesting_key: vault_key_name

salt/salt/pillar/vault.py

Lines 100 to 124 in 97e9395

	#Nesting Key not defined
	local:
	----------
	salt-passwd:
	badpasswd1
	root-passwd:
	rootbadpasswd1
	minion-passwd:
	minionbadpasswd1
	#Nesting Key defined
	local:
	----------
	keyname1:
	----------
	salt-passwd:
	badpasswd1
	root-passwd:
	rootbadpasswd1
	keyname2:
	----------
	minion-passwd:
	minionbadpasswd1

Note that the previous behavior also senselessly included the returned metadata key in the pillar.

[vshalchian]

Great. I have tested and it worked. Thank you