Support hierarchical partition keys for Azure Cosmos

[Kumima]

Description

Support hierarchical partition keys for Azure Cosmos and make both AzureInfrastructure and emulator respect the hierarchical partition keys.

As @davidfowl suggested, this won't introduce any break changes. A nullable property which is PartitionKeyPaths has been introduced, and when initializes a new instance of the AzureCosmosDBContainerResource, the first key will be used as the required parameter.

Similar with the Azure Cosmos SDK, only the PartitionKeyPaths will provide the partition key info.

The way to determine whether to use hierarchical partition keys to create the container is to check whether PartitionKeyPaths is null.

If there are further tests need to be added, let me know😊. Another thing I'm not sure is whether we should check the partition keys count, it should be <= 3.

Fixes #9462

Checklist

• Is this feature complete?
  • Yes. Ready to ship.
  • No. Follow-up changes expected.
• Are you including unit tests for the changes and scenario tests if relevant?
  • Yes
  • No
• Did you add public API?
  • Yes
    • If yes, did you have an API Review for it?
      • Yes
      • No
    • Did you add <remarks /> and <code /> elements on your triple slash comments?
      • Yes
      • No
  • No
• Does the change make any security assumptions or guarantees?
  • Yes
    • If yes, have you done a threat model and had a security review?
      • Yes
      • [] No
  • No
• Does the change require an update in our Aspire docs?
  • Yes
    • Link to aspire-docs issue (consider using one of the following templates):
      • New (or update) doc-idea template
      • New breaking-change template
      • New diagnostic template
  • No

[davidfowl]

@Kumima can update the cosmos playground example to use this feature?

[davidfowl]

@sebastienros @eerhardt thoughts here? This is the only sketchy part of this change. If there are many this property will only show the first one.

[sebastienros]

We could also obsolete this ctor and expose one with the keys. Then add a unit test to have coverage on both even if one is deprecated.

[Kumima]

Maybe we follow this, if hierarchical, single getter will throw. Or we can introduce a private/public ContainerProperties from AzureCosmosSdk to host the both type keys, so that we don't need to duplicated checking from AzureCosmosSdk.
https://github.com/Azure/azure-cosmos-dotnet-v3/blob/5e6232d25f84074d5008e97670d3e0dc07891f0e/Microsoft.Azure.Cosmos/src/Resource/Settings/ContainerProperties.cs#L408-L419

With public API of ContainerProperties seems bring more flexibility. Currently we can only custom the partition keys, not all those properties. And if this, we may also need to map all those properties for AzureProvisioning.

[davidfowl]

I prefer @sebastienros's suggestion, it's simpler.

[Kumima]

@davidfowl, please check the latest commits, I'm not sure whether those argument checking can be simplified. Are they a bit of duplicated?
And for:

[Obsolete("Use the overload that supports the hierarchical partition keys instead.")]
public AzureCosmosDBContainerResource(string name, string containerName, string partitionKeyPath, AzureCosmosDBDatabaseResource parent)
    : this(name, containerName, [partitionKeyPath], parent) { }

The argument exception comes from the other ctor. So given partitionKeyPath is null, we got partitionKeyPaths argument exception. Are we going to duplicated ctor logic here again?

[sebastienros]

We could also obsolete this ctor and expose one with the keys. Then add a unit test to have coverage on both even if one is deprecated.

[davidfowl]

Looks good!

[Kumima]

Looks good!

Can you take a look at the failed Linux test?

[davidfowl]

Thanks @Kumima !