Support secrets in tool requirements

[arash77]

Related to #19196
Closes #17511
Work in progress...
I will add a full description when it is done.

Adding secrets to tool requirements like this:

<requirements>
    <secret type="vault" user_preferences_key="some_tool/api_key" inject_as_env="some_tool_api_key" label="API Key" required="true"/>
</requirements>

This will make use of the vault key that has been added in user_preferences_extra:

preferences:
  some_tool:
    description: Your Tool settings
    inputs:
      - name: api_key
        label: API Key
        type: secret
        store: vault
        required: False

And inject it as an environmental variable that could be accessed within tools.

How to test the changes?

(Select all options that apply)

• I've included appropriate automated tests.
• This is a refactoring of components with existing test coverage.
• Instructions for manual testing are as follows:
  1. [add testing steps and prerequisites here if you didn't write automated tests covering all your changes]

License

• I agree to license these and all my past contributions to the core galaxy codebase under the MIT license.

[jmchilton]

Do any of the use cases involve multiple tools with different IDs requesting the same secret? If not - I would make the tool id (without a version) an implicit prefix here and just attach some similar field as the suffix. This isolation feels more secure-ish to me - we wouldn't risk tools picking up other keys accidentally.

[arash77]

Well, in some use cases, maybe in the future, it will be good to access an api_key or a token for multiple tools.

[yvanlebras]

Hi John, Arash, with @Marie59 and @jeremyfix we have such use case (if I well understand) where separate tools need the same credential (here this is Copernicus marine system credentials), so I confirm that this is already a reality ;) It appears to me, at least for ecology and related environmental sciences, that it will be the case for many data providers as Copernicus for satellites remote sensing data and others.

[nuwang]

Nice to see this feature coming in. One thing I was wondering about though, should this be a requirement or be injected through the <environment_variables> section following the precedent here?
#15300

[nuwang]

Suggested change

	seperated_key = user_preferences_key.split("/")
	if len(seperated_key) != 2 or not seperated_key[0] or not seperated_key[1]:
	separated_key = user_preferences_key.split("/")
	if len(separated_key) != 2 or not separated_key[0] or not separated_key[1]:

[arash77]

Thank you for the suggestion, but they will all change.
the new discussed plan is in #19196
I am not sure if this should go into environment_variables or not.