fix: Force partition key parameter and Fix hierarchical partition key deployment and analytical store enablement

[bryansan-msft]

Description

• Added more tests covering most NoSQL API and Account focused configurations.
• Removed non-related NoSQL API tests from its test suite (They were already covered by waf-aligned and plain test suite).
• Make partition key path parameter mandatory. It couldnt be optional in the first place anyways as it gives an error in deployment time
  • Fixes [AVM Module Issue]: PartitionKey should be required by the container resource for a NoSQL database #1222
• Add "/" to partition key path if the user doesn't specify it to avoid errors when it's missing
• Added user defined types for better consumer experience and intelisense.
  • Closes [AVM Module Issue]: Support IntelliSense when creating account, sql database and containers #1227
• Fixed an issue where deployment of a hierarchical partition key would fail even though it was allowed through parameter.
  • Fixes [AVM Module Issue]: Cannot enable hierarchical partitions keys as it needs partition key version 2 #1229
• Fixed an issue where you were forced to have RUs both in Container and Database due to default values being used. It was impossible to have RUs only at one level
  • Fixes [AVM Module Issue]: Cannot only specify throughput at container level or database level #1226
• Fixed an issue where analytical store ttl couldn't be enabled since there was missing a parameter (enableAnalyticalStore) at account level
  • Fixes [AVM Module Issue]: Cannot enable analytical store since there is no way to enable synapse link which is a pre-requisite  #1225
• Allow disabling local auth for NoSQL API as it is the recommended configuration when using managed identities
  • Closes [AVM Module Issue]: Allow disabling local auth #1228

Closes Azure/ResourceModules#4278

Remarks

• I have had to hardcode the region where the tests are being deployed to eastus as the pipeline is picking up a random region which might have new cosmosdb constraints or not supported features that the tests need. In my opinion is better to hardcode the region rather than remove the tests. I didn't find a way to tell the pipeline to deploy to specific regions without affecting all pipelines.

Pipeline Reference

Pipeline

Type of Change

• Update to CI Environment or utlities (Non-module effecting changes)
• Azure Verified Module updates:
  • Bugfix containing backwards compatible bug fixes, and I have NOT bumped the MAJOR or MINOR version in version.json:
    • Someone has opened a bug report issue, and I have included "Closes #{bug_report_issue_number}" in the PR description.
    • The bug was found by the module author, and no one has opened an issue to report it yet.
  • Feature update backwards compatible feature updates, and I have bumped the MINOR version in version.json.
  • Breaking changes and I have bumped the MAJOR version in version.json.
  • Update to documentation

Checklist

• I'm sure there are no other open Pull Requests for the same update/change
• I have run Set-AVMModule locally to generate the supporting module files.
• My corresponding pipelines / checks run clean and green without any errors or warnings

[bryansan-msft]

@AlexanderSehr Readme problem is already solved, changes are already implemented and new pipeline run is green.