Loads secrets in parallel

[pakrym]

Fixes: #910

[pakrym]

This is technically a breaking change. We now require thread safety from customer provided IKeyVaultSecretManager implementations where it wasn't required before.

On the other hand it's inlikely that IKeyVaultSecretManager implementations would contain any non-thread safe state considering it's purpose is filtering and transforming secret names into configuration key names.

    /// <summary>
    /// The <see cref="IKeyVaultSecretManager"/> instance used to control secret loading.
    /// </summary>
    public interface IKeyVaultSecretManager
    {
        /// <summary>
        /// Checks if <see cref="SecretItem"/> value should be retrieved.
        /// </summary>
        /// <param name="secret">The <see cref="SecretItem"/> instance.</param>
        /// <returns><code>true</code> is secrets value should be loaded, otherwise <code>false</code>.</returns>
        bool Load(SecretItem secret);

        /// <summary>
        /// Maps secret to a configuration key.
        /// </summary>
        /// <param name="secret">The <see cref="SecretBundle"/> instance.</param>
        /// <returns>Configuration key name to store secret value.</returns>
        string GetKey(SecretBundle secret);
    }

/cc @muratg @Eilon

[Eilon]

Out of curiosity, with this change, what is the time delta in the scenario of ~79 secrets being loaded?

[Eilon]

As far as breaking changes go, I agree with the assessment. Can we update the doc comments for the affected types/methods to indicate the thread safety requirements?

[pakrym]

Not a breaking change anymore. All IKeyVaultSecretManager interactions are done on the same thread now.

[pakrym]

@Eilon our connection to KeyVault is pretty good so on my machine with 100 secrets load time went from 11 to 7 sec. I would imagine much better results on machines with slower access to keyvault.

[pakrym]

@gfoidl thank you for the review!