Update MaxQueuePollingInterval default for Flex Consumption apps

[bachuv]

This PR updates the MaxQueuePollingInterval to a default of 1 second instead of 30 seconds if the app is running on a Flex Consumption plan to help with cold start latency specific to Durable Functions Flex Consumption apps.

Note: This is a draft PR since we need to finalize if 1 second is the new default we would like to go with for Flex Consumption apps.

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)
• My changes do not require any extra work to be leveraged by OutOfProc SDKs
  • Otherwise: That work is being tracked here: #issue_or_pr_in_each_sdk
• My changes do not change the version of the WebJobs.Extensions.DurableTask package
  • Otherwise: major or minor version updates are reflected in /src/Worker.Extensions.DurableTask/AssemblyInfo.cs
• My changes do not add EventIds to our EventSource logs
  • Otherwise: Ensure the EventIds are within the supported range in our existing Windows infrastructure. You may validate this with a deployed app's telemetry. You may also extend the range by completing a PR such as this one.
• My changes should be added to v3.x branch.
  • Otherwise: This change only applies to Durable Functions v2.x and will not be merged to branch v3.x.

[cgillum]

The change looks good to me! I think we just need to add some code comments explaining why we have this new logic (to remind our future selves and/or future maintainers).

[cgillum]

Oh, and let's make sure we update the release notes with this information so that we have this change nicely documented for people to see.

[AnatoliB]

If I'm reading this implementation correctly, this get will always override the maxQueuePollingInterval field with the default based on the env variable, so set will not even matter, which is probably not the intent. Consider adding a unit test that confirms that the value passed to set is actually returned by the next get. On the implementation side, consider using Lazy<TimeSpan> for maxQueuePollingInterval.

[cgillum]

Ah, I totally missed that. Good call - we need to check to see whether the value has been initialized already and not initialize it again. Another option to consider is defaulting to a dummy value, like TimeSpan.Zero which has the benefit of being a non-breaking change.

[bachuv]

I added a change to check for if this.maxQueuePollingInterval == TimeSpan.Zero (since TimeSpan.Zero is the default value for TimeSpan) before setting the queue polling default setting. If it's not TimeSpan.Zero, then it just returns the current value of this.maxQueuePollingInterval. Is this a reasonable fix or should I go with another approach (e.g. using Lazy<TimeSpan>)?

I also added unit tests for AzureStorageOptions.

[AnatoliB]

The Lazy<TimeSpan> idea will not actually work because Lazy doesn't have a setter, and I forgot about it. Your approach makes sense, thank you.