200 & 300 level tutorials & docs supporting azure-client

[ssimic2]

As part of https://github.com/microsoft/FluidFramework/issues/8849 we are looking to create 200 & 300 level tutorials/classes on ff.com. The set of tutorials & documentation offered through this epic should empower new users to adopt FF in their existing apps, while answering more nuanced questions and requirements around integration and general observability.

Approach

We will structure tutorials/docs in a format that supports natural progression through various learning milestones. At the same time, the topics should be clear enough where reader can search and find specific points of interests. We will use existing doc sections https://fluidframework.com/docs/recipes/ and https://fluidframework.com/docs/build/, reworked for 200 and 300 level purpose. https://fluidframework.com/docs/start should still be used a quick-start.

Topics

Each of the following topics should be concise enough to be self-contained task. In this epic we are focusing on client-side data. Follow up epic will cover extended topics around auth., clients/quorum, nodejs/services etc.

• [x] #10112
• [x] #10113
• [x] #10114
• [x] #10115
• [x] #10116
• [ ] User should: know how to correlate FF and "source of truth" data. The question often comes why we cannot create containers having the same ID as some external entity. We should answer those questions here while focusing on general lifecycle of FF data.
• [ ] User should: find FF system to generally be "observable" (open topic) with highlight on performance / telemetry / error logging.
• [ ] User should: know how to set up unit tests and e2e tests for FF containers.
• [ ] User should: know how interpret and handle various states and error conditions - connected/disconnected, attached/detached, saved/dirty - we need to understand if the matrix is simple to interpret, errors are clear etc.
• [ ] User should: understand FF system in the context of offline work.
• [ ] User should: understand how to upgrade document schema, and generally be well versed with upgrades.
• [ ] User should: be comfortable in choosing appropriate optimistic data structure, while being clear on constraints. Here we will go into DDS details.
• [ ] User should: be comfortable in choosing appropriate consensus data structure, while being clear on constraints. User should be clear when NOT to use them.