Prevent adding PlaceholderResolver multiple times

[bart-vmware]

Description

Fixed: Prevent adding PlaceholderResolver multiple times, which breaks the ENV actuator.

Quality checklist

• Your code complies with our Coding Style.
• You've updated unit and/or integration tests for your change, where applicable.
• You've updated documentation for your change, where applicable.
  If your change affects other repositories, such as Documentation, Samples and/or MainSite, add linked PRs here.
• There's an open issue for the PR that you are making. If you'd like to propose a new feature or change, please open an issue to discuss the change or find an existing issue.
• You've added required license files and/or file headers (explaining where the code came from with proper attribution), where code is copied from StackOverflow, a blog, or OSS.

[TimHess]

/azp run Steeltoe.All

[azure-pipelines]

Azure Pipelines successfully started running 1 pipeline(s).

[TimHess]

LGTM as-is, only thought is we could log when it isn't added so the user knows they can remove the extra entry

[sonarqubecloud]

Quality Gate passed

Issues
0 New issues
0 Accepted issues

Measures
0 Security Hotspots
0.0% Coverage on New Code
0.0% Duplication on New Code

See analysis details on SonarCloud

[bart-vmware]

LGTM as-is, only thought is we could log when it isn't added so the user knows they can remove the extra entry

Oh, I saw your comment after merging. We could, but AddPlaceholderResolver is sometimes called by other Steeltoe code: Bootstrap, Config Server, Management. In that case, the user can't fix it. I don't think we should warn in those cases. Also, it's pretty common to run registrations multiple times in ASP.NET. For example, AddOptions, AddLogging etc are called multiple times, just to make sure the basics are in place.

[fennekit]

I think this also applies to the EncryptionResolver (see. EncryptionConfigurationExtensions.cs)

[bart-vmware]

@fennekit Thanks, I think you're right.

I've created this PR because we've had internal reports from people explicitly calling .AddPlaceholderResolver() and .AddConfigServer() (where the latter implicitly calls this method as well), resulting in problems, such as the ENV endpoint not listing all of the configuration providers.

This problem is less likely to occur with EncryptionResolver because (as far as I'm aware) there's no other Steeltoe code implicitly calling AddEncryptionResolver. However, it doesn't hurt to apply the same safeguard there. Would you be interested in creating a PR for that?

[fennekit]

@bart-vmware OK. I will create a PR in the coming week.