Add ADR for large message chunking in MQTT protocol

Author: maximsemenov80

doc/dev/adr/0020-large-message-chunking.md

@@ -0,0 +1,57 @@
+# ADR 20: Large Message Chunking in MQTT Protocol
+
+## Status
+Proposed
+
+## Context
+The MQTT protocol has inherent message size limitations imposed by brokers and network constraints. Azure IoT Operations scenarios often require transmitting payloads that exceed these limits (e.g., firmware updates, large telemetry batches, complex configurations). Without a standardized chunking mechanism, applications must implement their own fragmentation strategies, leading to inconsistent implementations and interoperability issues.
+
+## Decision
+We will implement protocol-level message chunking as part of the MQTT protocol layer by using MQTT user properties to carry chunk metadata. This approach will make the chunking mechanism explicit in the protocol rather than hiding it in higher or lower layers.
+
+The chunking mechanism will:
+1. Be applied only to MQTT PUBLISH packets
+2. Use standardized user properties for chunk metadata:
+   - `__ci`: Chunk index in the sequence (0-based)
+   - `__tc`: Total number of chunks in the complete message
+   - `__mid`: Original message identifier for reassembly
+   - `__cs`: Optional hash/checksum of complete payload
+
+### Protocol Flow
+**Sending Process:**
+- When a payload exceeds the maximum packet size, the client intercepts it before transmission
+- The message is split into fixed-size chunks (with potentially smaller last chunk)
+- Each chunk is sent as a separate MQTT message with the same topic but with chunk metadata.
+- Any user properties and additional metadata not mandated by the MQTT protocol to appear in every message, originally set on the initial PUBLISH packet, will be included only in the first chunk.
+- QoS settings are maintained across all chunks.
+
+**Receiving Process:**
+   - The MQTT client receives messages and identifies chunked messages by the presence of chunk metadata.
+   - Chunks are stored in a temporary buffer, indexed by message ID (`__mid`) and chunk index (`__ci`).
+   - When all chunks for a message ID are received, they are reassembled in order.
+   - The reconstructed message is then processed as a single message by the application callback.
+
+## Consequences
+
+### Benefits
+- **Standards-Based:** Uses existing MQTT features rather than custom transport mechanisms
+- **Protocol Transparent:** Makes chunking behavior explicit in the protocol
+- **Property Preservation:** Maintains topic, QoS, and other message properties consistently
+- **Network Optimized:** Allows efficient transmission of large payloads over constrained networks
+
+### Implementation Considerations
+- **Error Handling:**
+  - Chunk timeout mechanisms
+  - Missing chunk detection
+  - Error propagation to application code
+- **Performance Optimization:**
+  - Dynamic chunk sizing based on broker limitations
+  - Concurrent chunk transmission
+  - Efficient memory usage during reassembly
+- **Security:**
+  - Validate message integrity across chunks
+  - Prevent chunk injection attacks
+
+## Open Questions
+1. How do we determine the optimal chunk size? Should it be based on the broker's max size, network conditions, or configurable by the application?
+2. Do we create a new API method (`PublishLargeAsync()`) or use the existing `PublishAsync()` API with transparent chunking for oversized payloads?