type checking work across repo

[kristapratico]

Mypy and pyright are static type checkers that can be run on code to evaluate type annotations and find bugs. The type annotations we write in our code ship as part of our client libraries and our developer customers rely on our typing as a further check of the code that they're writing. Therefore, it is important that we not only write type annotations into our client libraries, but also that these typing annotations are accurate and pass by the type checkers. We are aware of the customer impact of having incorrect type annotations shipped in our packages: https://github.com/Azure/azure-sdk-for-python/issues/20157 https://github.com/Azure/azure-sdk-for-python/issues/21223 https://github.com/Azure/azure-sdk-for-python/issues/20083 https://github.com/Azure/azure-sdk-for-python/issues/21847 https://github.com/Azure/azure-sdk-for-python/issues/23362

In our repo, we currently run mypy as part of CI on all libraries that opt-in on this list. This means that any new library must intentionally add themselves to the allow list to enable type checking on their library. We would like to change this workflow such that mypy and pyright is always run on every library unless that library is placed on a blocklist. This would match the workflow we have with our other static analysis checker, pylint.

To make this a reality, there are a few steps we must take:

1. Decide the list of libraries we don't want to run mypy/pyright on and move them to a blocklist.

2. Work towards getting our entire repo "type checker clean" (aka fix all the typing errors present in our code). Running mypy on all of the data-plane libraries in our repo results in 44 libraries that currently raise mypy errors:

   azure-agrifood-farming
   azure-ai-anomalydetector
   azure-ai-language-conversations
   azure-ai-language-questionanswering
   azure-applicationinsights
   azure-batch
   azure-common
   azure-communication-chat*
   azure-communication-identity*
   azure-communication-networktraversal*
   azure-communication-phonenumbers*
   azure-communication-sms*
   azure-confidentialledger
   azure-containerregistry*
   azure-core-tracing-opencensus
   azure-core-tracing-opentelemetry
   azure-cosmos
   azure-digitaltwins-core*
   azure-graphrbac
   azure-iot-deviceupdate
   azure-iot-modelsrepository
   azure-loganalytics
   azure-media-analytics-edge
   azure-media-videoanalyzer-edge
   azure-messaging-webpubsubservice
   azure-mixedreality-authentication*
   azure-monitor-opentelemetry-exporter
   azure-monitor-query*
   azure-purview-administration
   azure-purview-catalog
   azure-purview-scanning
   azure-schemaregistry-avroencoder*
   azure-schemaregistry*
   azure-search-documents*
   azure-security-attestation*
   azure-servicefabric
   azure-storage-blob-changefeed
   azure-storage-blob
   azure-storage-file-datalake
   azure-storage-file-share
   azure-storage-queue
   azure-synapse-accesscontrol
   azure-synapse-artifacts
   azure-synapse
   

   9 of these libraries contain "fatal errors" in which mypy is prevented from further running checks:

   azure-communication-chat #23265 azure-communication-identity #23265 azure-communication-networktraversal #23265 azure-communication-phonenumbers #23265 azure-communication-sms #23265 azure-security-attestation #23357

Edit: using the below config options, this is more like 65 libraries failing mypy and 67 failing with pyright.

3. Docs! If we intend to enable type checking across the repo, it's vital that we have thorough docs which help our team, partner teams, open source contributors, etc. adapt and understand how to fix common typing errors. The docs should contain general typing tips and typing guidance as it relates to common types/patterns we use in the Python SDK. We should additionally touch on how/when it is appropriate to ignore a typing error and what further steps should be taken. Once this document exists, it should be linked to any failures that occur in CI to help assist in fixing any errors. edit: after we're done with doc, we should work on translating this into DO/DON'T type format for guidelines

4. We should set up mypy/pyright in CI to run not only on our src code, but also on the samples for each client library. This will capture how our users use mypy/pyright with our libraries and ensure that we have correct type hinting and no errors.

5. Consider which command line arguments we might want to pass into the type checker and how to manage global config for the entire repo. For example, https://github.com/Azure/azure-sdk-for-python/issues/23824