aspire compatible facade for cosmos global distributed lock

[secheledelaruse]

this follows up an earlier idea of an aspire facade for the cosmos db global distributed lock design pattern listed here

execution summary
the canonical distributed lock strategy is amenable to abstraction with dependency injection

my back of the napkin analysis suggests that independent client consumption of the api surface requires only each client to maintain its own lock ownership state, which leverages global atomicity via the underlying cosmos lock lease with ownership information updatable and queryable by any client

to do

• show whether consuming clients should specify a cosmos resource in their app.host and consume this resource via a client integration. this would permit the cloud native opinions in app host like observability, resiliance etc. perhaps this resource cculd expose the target cosmos container
• prove correctness
• shape the repo like the community toolkit
• read further in the documentation

accomplished so far in this repo

abstracted design pattern guidance example code with dependency injection friendly interfaces and api surface

first cut of aspire custom client integration with simple settings that require a url and registers the ecosystem of dependent services in di

working on integrating the canonical azure durable functions say hello orchestration with a timer trigger interlocked with the lease duration for distribued locks

if this interests you

• i don't yet know how to reference a cosmos resource registered in apphost from a custom client integration, or whether there should be a custom resource that wraps a cosmos resource with extra config, and if the latter is even possible

regards