Azure/iotedge/doc/images

[main] Device product information (#6262) Currently, the edge agent encodes some runtime information (e.g. EdgeAgent and .NET versions) as part of the product information connection parameter, which can then be used to examine device characteristics from management interfaces. Some users desire the ability to add system-level properties--such as kernel version--to the product information. This PR adds a configuration option for custom product information strings as well as an automated option which augments the existing runtime information with the following system parameters: - kernel name, release, architecture - OS name, release - system name, version, vendor Generated files: - edge-agent/src/Microsoft.Azure.Devices.Edge.Agent.Edgelet/version_2021_12_07/generatedCode/EdgeletHttpClient.cs Largely duplicated files: - edge-agent/src/Microsoft.Azure.Devices.Edge.Agent.Edgelet/version_2021_12_07/ModuleManagementHttpClient.cs - edgelet/api/managementVersion_2021_12_07.yaml ### General Guidelines and Best Practices - [x] I have read the [contribution guidelines](https://github.com/azure/iotedge#contributing). - [x] Title of the pull request is clear and informative. - [x] Description of the pull request includes a concise summary of the enhancement or bug fix. ### Testing Guidelines - [x] Pull request includes test coverage for the included changes. - Description of the pull request includes - [ ] concise summary of tests added/modified - [x] local testing done.

Add documentation for route priority and TTL (#2921) Add documentation for route priority and TTL

Add agent to custom network (#2318) Currently, when edge agent is started by iotedged for the first time (container doesn't already exist on the host) it is added to the default docker network, e.g., "bridge" on Linux. When the agent's container is upgraded by the deployment (i.e., the deployment specifies a docker image that doesn't match what was given in config.yaml), it is added to the network specified by config.yaml's `moby_runtime.network[.name]` field, e.g., "azure-iot-edge" by default on Linux. This behavior was inadvertently introduced a long time ago (see e2006e0a4). The common case seems to be to use the default `mcr.microsoft.com/azureiotedge-agent:1.0` image to bootstrap then change to a specific image in the deployment, so for most people the agent lives in the right network most of the time. And even if it's added to the default network instead, that's usually not a problem, which probably explains why this hasn't been an issue. I ran into it while working on the new diagnostics feature (the agent needs to connect to edge hub's Prometheus endpoint, but it's in a different network so it can't resolve the name). This change makes the behavior more consistent. Now, when the daemon creates the agent container, it will add it to the custom network--the same network it will live on if it ever gets upgraded by a deployment.

Add doc explaining IoT Edge networking (#360) * Add doc explainning iot edge networking * Update network diagram * Address review comments

Merged PR 750502: Provisioning doc Wrote up current thinking on provisioning Edge. It only covers SAS token provisioning. It does not include Edgelet steps beyond getting device credentials namely key derivation for modules, getting the agent twin and updating identities in the cloud. I wasn't considering those steps as part of provisioning, but I can add them if folks think this is the right place for it. Working on teardown steps. Also working on clarifying some of the open questions. They wouldn't change the design drastically, just simplify some aspects.

Merged PR 739214: Update release steps Update release steps to include all the steps. This should make it easy for anyone on the team to do Edge releases.

Merged PR 691217: Added Edgelet proto interface and E2E security document What started of as a project to come up with a proto interface between Edgelet <--> Modules, it quickly became apparent that there needs to be an investigation of how security is to be implemented E2E. It began with how will the GRPC interfaces be called from modules and how to integrate with the SDK, followed by how do the requests get handled in the Edgelet. So with that said, this PR has a doc and proto interface. A few details are still TBD and have been called out but more less most of everything needed for GA is covered along with a path towards X.509 auth. - For the benefit of reviewers, I would suggest clicking the MD file in VSTS followed by the preview button :)

Merged PR 628229: Add AMQP head with SAS authentication support This PR should be considered as _in progress_ right now. While the SAS authentication is implementation complete, I haven't really tested it with a Device SDK client because there are other pieces that need to be in place before we can do that. The following files in this PR are there only to make stuff compile and isn't ready for review: 1. AmqpConnectionGatewayContext.cs 2. AmqpRuntimeProvider.cs Begin the review by reading `/doc/AmqpBootstrapImplementationNotes.md`. That should give you an idea about how AMQP SASL authentication works. `AmqpProtocolHead.cs` is the entrypoint - this object's `StartAsync` method is invoked when the Edge Hub service starts. `EdgeHubSaslPlainAuthenticator.cs` contains the code that implements SAS authentication.

Merged PR 606572: Rename files because Linux file systems are case sensitive Rename files because Linux file systems are case sensitive

Merged PR 583636: Merge angelod/ModuleToCloudSequenceDiagram to master I will add the sequences Diagrams and updating the Class Diagram on the visio file, before referencing it on the documentation. If we find value on publishing it, we can update the .md file pointing to them and keep updating it.

Merged PR 576875: Merge angelod/updatingDocuments to master The goal of this 1st PR is to ADD the Visio Diagram document to our repo, so everybody can edit and make changes to our design doc for Edge Hub. So, this change has: -Very minor fixes that I have identified; -Adding Class Diagram do our main Readme file; -Renaming tabs on our visio diagram file. *This PR does not update the overall design, since this is a large effort and should be done by whoever change the code or has more specific knowledge.

Merged PR 482936: Add documentation for the release process This documents the release process for images using VSTS build/release jobs.

Merged PR 334819: Add developer documentation Add developer documentation Related work items: #1250700