Availability: Adds account-level read regions as effective preferred regions when preferred regions is not set on client.

[jeet1995]

Pull Request Template

Problem Statement

As of today, customers who do not configure ApplicationPreferredRegions or ApplicationRegion are pinned to either the hub region (in multi-write accounts) or the primary region (in single-write accounts). In outage scenarios, availability is scoped to just a single region and is not ideal (both reads/writes in multi-write accounts and reads in single-write multi-region accounts have their availability curbed to just the one region). Setting ApplicationPreferredRegions or ApplicationRegion as empty is not an opt-out of availability decision from the customer's perspective unless of course on the client a regional endpoint has been set. This PR aims to fix this issue when preferred regions is not set, and a global endpoint is set on the client.

Approach taken in this PR

The idea is to construct an effective preferred region list and to rely on account-level read and account-level write regions for it. If there is client-perceived unavailability or account-level topology changes - then this effective preferred regions list is reordered accordingly or reflects the account-level regions post a cached DatabaseAccount refresh in the SDK.

There are also changes made to the flow which decides when DatabaseAccount refresh is triggered. The decision depends on a check whether the SDK has a different effective first preferred read / write region from the first account-level read / write region.

Closing issues

closes #4665

[github-actions]

All good!

[kundadebdatta]

Doesn't look like there are any changes here. Could you please fix this (and the other places) ? This really helps to focus on the actual diffs.