Allow custom connection string names when creating a DurableClient in an ASP.NET Core app

[bachuv]

This PR allows customers to use custom app setting names to create a DurableClient in an ASP.NET Core app.

_client = clientFactory.CreateClient(new DurableClientOptions
          {
              ConnectionName = "Storage",
              TaskHub = configuration["TaskHub"]
          });

Currently, customers have to set ConnectionName to "Storage" in DurableClientOptions because of this line in AzureStorageDurabilityProviderFactory.cs. connectionName is always set to null which means that it's always set to the this.defaultConnectionName. this.defaultConnectionName defaults to using ConnectionStringNames.Storage which is "Storage" because this.azureStorageOptions.ConnectionStringName` is null in this flow.

This PR passes the ConnectionName and TaskHub name from DurableClientOptions to GetAzureStorageOrchestrationServiceSettings() to create an AzureStorageDurabilityProvider using the configured values instead of default values.

Resolves #1656

Pull request checklist

• My changes do not require documentation changes
  • Otherwise: Documentation PR is ready to merge and referenced in pending_docs.md
• My changes should not be added to the release notes for the next release
  • Otherwise: I've added my notes to release_notes.md
• My changes do not need to be backported to a previous version
  • Otherwise: Backport tracked by issue/PR #issue_or_pr
• I have added all required tests (Unit tests, E2E tests)

[ConnorMcMahon]

I think this is very close.

I have a couple of minor production code suggestions, and a few questions/suggestions about the tests.

[ConnorMcMahon]

I am a little concerned about changing this, just because some customers will be running in non-webjobs scenario.

[bachuv]

I initially changed it because of this comment in the linked issue:

In addition when consuming this service via non web job (standard aspnet application) the extention method defaults to using the implementation of IConnectionStringProvider as StandardConnectionStringProvider.

After looking the source code it appears that the standard implementation would be better suited using WebJobsConnectionStringProvider this will locate connection string via both local.settings.json:Values:ConnString in webjob and appsettings.json:ConnectionStrings:ConnString in standard ASP.NET application and therefore feels like the naming convention of these implementations are reversed.

I can change it back to StandardConnectionStringProvider. I looked through StandardConnectionStringProvider and WebJobsConnectionStringProvider to understand this comment and the only difference I see is that WebJobsConnectionStringProvider evaluates configuration.GetConnectionString(connectionName) first before configuration[connectionName]. I'm not exactly clear on what configuration.GetConnectionString(connectionName) does/where it looks for connection strings. Let me know if you think WebJobsConnectionStringProvider is fine otherwise I'll change it to StandardConnectionStringProvider

azure-functions-durable-extension/src/WebJobs.Extensions.DurableTask/StandardConnectionStringProvider.cs

Line 31 in cc7f8b2

return this.configuration[connectionStringName];

azure-functions-durable-extension/src/WebJobs.Extensions.DurableTask/WebJobsConnectionStringProvider.cs

Line 29 in cc7f8b2

return this.hostConfiguration.GetWebJobsConnectionString(connectionStringName);

https://github.com/Azure/azure-webjobs-sdk/blob/4a16c273b40ee47ec318bb6d7aa12e0075f30402/src/Microsoft.Azure.WebJobs.Host/Extensions/IConfigurationExtensions.cs#L79

[ConnorMcMahon]

LGTM!