Merge branch 'feature/improve_doc_link_check' into 'master'

docs: fix broken links and re-enable linkchecker

Closes IDF-2640

See merge request espressif/esp-idf!17919

docs/en/api-reference/api-conventions.rst

@@ -9,7 +9,7 @@ ESP-IDF provides several kinds of programming interfaces:
 
 * C functions, structures, enums, type definitions and preprocessor macros declared in public header files of ESP-IDF components. Various pages in the API Reference section of the programming guide contain descriptions of these functions, structures and types.
 * Build system functions, predefined variables and options. These are documented in the :ref:`build system guide<cmake_buildsystem_api>`.
-* `Kconfig <kconfig>`_ options can can be used in code and in the build system (CMakeLists.txt) files.
+* :doc:`Kconfig <kconfig>` options can can be used in code and in the build system (CMakeLists.txt) files.
 * :doc:`Host tools <../api-guides/tools/index>` and their command line parameters are also part of ESP-IDF interface.
 
 ESP-IDF consists of components written specifically for ESP-IDF as well as third-party libraries. In some cases, an ESP-IDF-specific wrapper is added to the third-party library, providing an interface that is either simpler or better integrated with the rest of ESP-IDF facilities. In other cases, the original API of the third-party library is presented to the application developers.
@@ -96,7 +96,7 @@ It is not recommended to reference these components directly in custom projects
 API Stability
 -------------
 
-ESP-IDF uses `Semantic Versioning <http://semver.org/>`_ as explained in the :ref:`versions page<versioning-scheme>`.
+ESP-IDF uses `Semantic Versioning <https://semver.org/>`_ as explained in the :ref:`versions page<versioning-scheme>`.
 
 Minor and bugfix releases of ESP-IDF guarantee compatibility with previous releases. The sections below explain different aspects and limitations to compatibility.
 
@@ -109,7 +109,7 @@ The following changes are allowed between minor versions and do not break source
 
 * Deprecating functions (using the ``deprecated`` attribute) and header files (using a preprocessor ``#warning``). Deprecations are listed in ESP-IDF relese notes. It is recommended to update the source code to use the newer functions or files that replace the deprecated ones, however this is not mandatory. Deprecated functions and files can be removed in major versions of ESP-IDF.
 * Renaming components, moving source and header files between components — provided that the build system ensures that correct files are still found.
-* Renaming Kconfig options. Kconfig system `renaming mechanism <configuration-options-compatibility>`_ ensures that the original Kconfig option names can still be used by the application in ``sdkconfig`` file, CMake files and source code.
+* Renaming Kconfig options. Kconfig system :ref:`renaming mechanism <configuration-options-compatibility>` ensures that the original Kconfig option names can still be used by the application in ``sdkconfig`` file, CMake files and source code.
 
 Lack of binary compatibility
 ^^^^^^^^^^^^^^^^^^^^^^^^^^^^
@@ -132,7 +132,7 @@ While we try to make upgrading to a new ESP-IDF version easy, there are parts of
 * Changes made to mitigate security issues or to replace insecure default behaviors with a secure ones.
 * Features which were never functional. For example, if it was never possible to use a certain function or an enumeration value, it may get renamed (as part of fixing it) or removed. This includes software features which depend on non-functional chip hardware features.
 * Unexpected or undefined behavior (for example, due to missing validation of argument ranges) that is not documented explicitly may be fixed/changed.
-* Location of `Kconfig <kconfig>`_ options in menuconfig.
+* Location of :doc:`Kconfig <kconfig>` options in menuconfig.
 * Location and names of example projects.
 
 .. _designated initializers: https://en.cppreference.com/w/c/language/struct_initialization

docs/en/api-reference/bluetooth/index.rst

@@ -12,7 +12,7 @@ Bluetooth API
     controller_vhci
     esp-ble-mesh
     nimble/index
-    
+
 ESP-IDF currently supports two host stacks. The Bluedroid based stack (default) supports classic Bluetooth as well as BLE. On the other hand, Apache NimBLE based stack is BLE only. For users to make a choice:
 
 * For usecases involving classic Bluetooth as well as BLE, Bluedroid should be used.
@@ -22,7 +22,7 @@ ESP-IDF currently supports two host stacks. The Bluedroid based stack (default)
 
     For the overview of the ESP32 Bluetooth stack architecture, follow the links below:
 
-       * `ESP32 Bluetooth Architecture (PDF) <http://espressif.com/sites/default/files/documentation/esp32_bluetooth_architecture_en.pdf>`_
+       * `ESP32 Bluetooth Architecture (PDF) <https://espressif.com/sites/default/files/documentation/esp32_bluetooth_architecture_en.pdf>`_
 
 Code examples for this API section are provided in the :example:`bluetooth/bluedroid` directory of ESP-IDF examples.
 

docs/en/api-reference/bluetooth/nimble/index.rst

@@ -3,7 +3,7 @@ NimBLE-based host APIs
 Overview
 ========
 
-Apache MyNewt NimBLE is a highly configurable and BT SIG qualifiable BLE stack providing both host and controller functionalities. ESP-IDF supports NimBLE host stack which is specifically ported for ESP32 platform and FreeRTOS. The underlying controller is still the same (as in case of Bluedroid) providing VHCI interface. Refer to  `NimBLE user guide <http://mynewt.apache.org/latest/network/index.html#>`_ for a complete list of features and additional information on NimBLE stack. Most features of NimBLE including BLE Mesh are supported by ESP-IDF. The porting layer is kept cleaner by maintaining all the existing APIs of NimBLE along with a single ESP-NimBLE API for initialization, making it simpler for the application developers.
+Apache MyNewt NimBLE is a highly configurable and BT SIG qualifiable BLE stack providing both host and controller functionalities. ESP-IDF supports NimBLE host stack which is specifically ported for ESP32 platform and FreeRTOS. The underlying controller is still the same (as in case of Bluedroid) providing VHCI interface. Refer to  `NimBLE user guide <https://mynewt.apache.org/latest/network/index.html>`_ for a complete list of features and additional information on NimBLE stack. Most features of NimBLE including BLE Mesh are supported by ESP-IDF. The porting layer is kept cleaner by maintaining all the existing APIs of NimBLE along with a single ESP-NimBLE API for initialization, making it simpler for the application developers.
 
 Architecture
 ============

docs/en/api-reference/peripherals/sd_pullup_requirements.rst

@@ -197,7 +197,7 @@ If you use a development board without pull-ups, you can do the following:
 
     .. warning::
 
-        Burning eFuses is irreversible! The issue list above might be out of date, so please make sure that the module you are burning has a 3.3 V flash chip by checking the information on http://www.espressif.com/. If you burn the 3.3 V eFuses on a module with a 1.8 V flash chip, the module will stop functioning.
+        Burning eFuses is irreversible! The issue list above might be out of date, so please make sure that the module you are burning has a 3.3 V flash chip by checking the information on https://www.espressif.com/. If you burn the 3.3 V eFuses on a module with a 1.8 V flash chip, the module will stop functioning.
 
     If you are sure that you need to irreversibly burn eFuses, go to your ESP-IDF directory and run the following command:
 

docs/en/api-reference/peripherals/touch_pad.rst

@@ -25,7 +25,7 @@ In-depth design details of touch sensors and firmware development guidelines for
 
 .. only:: SOC_TOUCH_VERSION_1
 
-    For more information about testing touch sensors in various configurations, please check the `Guide for ESP32-Sense-Kit <https://github.com/espressif/esp-dev-kits/blob/master/esp32-sense-kit/docs/esp32_sense_kit_guide_en.md>`_.
+    For more information about testing touch sensors in various configurations, please check the `Guide for ESP32-Sense-Kit <https://docs.espressif.com/projects/espressif-esp-dev-kits/en/latest/esp32/esp32-sense-kit/user_guide.html>`_.
 
 Functionality Overview
 ----------------------

docs/en/api-reference/protocols/asio.rst

@@ -3,7 +3,7 @@ ASIO port
 
 Overview
 --------
-Asio is a cross-platform C++ library, see https://think-async.com. It provides a consistent asynchronous model using a modern C++ approach.
+Asio is a cross-platform C++ library, see https://think-async.com/Asio/. It provides a consistent asynchronous model using a modern C++ approach.
 
 
 ASIO documentation

docs/en/api-reference/protocols/esp_crt_bundle.rst

@@ -54,9 +54,9 @@ Generating the List of Root Certificates
 ----------------------------------------
 The list of root certificates comes from Mozilla's NSS root certificate store, which can be found `here <https://wiki.mozilla.org/CA/Included_Certificates>`_
 The list can be downloaded and created by running the script ``mk-ca-bundle.pl`` that is distributed as a part of `curl <https://github.com/curl/curl>`_.
-Another alternative would be to download the finished list directly from the curl website: `CA certificates extracted from Mozilla <https://curl.haxx.se/docs/caextract.html>`_
+Another alternative would be to download the finished list directly from the curl website: `CA certificates extracted from Mozilla <https://curl.se/docs/caextract.html>`_
 
-The common certificates bundle were made by selecting the authorities with a market share of more than 1 % from w3tech's `SSL Survey <https://w3techs.com/technologies/overview/ssl_certificate/all>`_.
+The common certificates bundle were made by selecting the authorities with a market share of more than 1 % from w3tech's `SSL Survey <https://w3techs.com/technologies/overview/ssl_certificate>`_.
 These authorities were then used to pick the names of the certificates for the filter list, `cmn_crt_authorities.csv`, from `this list <https://ccadb-public.secure.force.com/mozilla/IncludedCACertificateReportPEMCSV>`_ provided by Mozilla.
 
 

docs/en/api-reference/protocols/mbedtls.rst

@@ -1,7 +1,7 @@
 Mbed TLS
 ========
 
-`Mbed TLS <https://github.com/ARMmbed/mbedtls>`_ is a C library that implements cryptographic primitives, X.509 certificate manipulation and the SSL/TLS and DTLS protocols. Its small code footprint makes it suitable for embedded systems.
+`Mbed TLS <https://github.com/Mbed-TLS/mbedtls>`_ is a C library that implements cryptographic primitives, X.509 certificate manipulation and the SSL/TLS and DTLS protocols. Its small code footprint makes it suitable for embedded systems.
 
 .. note:: ESP-IDF uses a `fork <https://github.com/espressif/mbedtls>`_ of Mbed TLS which includes a few patches (related to hardware routines of certain modules like ``bignum (MPI)`` and ``ECC``) over vanilla Mbed TLS.
 

docs/en/api-reference/protocols/mdns.rst

@@ -7,7 +7,7 @@ Overview
 
 mDNS is a multicast UDP service that is used to provide local network service and host discovery.
 
-mDNS is installed by default on most operating systems or is available as separate package. On ``Mac OS`` it is installed by default and is called ``Bonjour``. Apple releases an installer for ``Windows`` that can be found `on Apple's support page <https://support.apple.com/downloads/bonjour%2520for%2520windows>`_. On ``Linux``, mDNS is provided by `avahi <https://github.com/lathiat/avahi>`_ and is usually installed by default.
+mDNS is installed by default on most operating systems or is available as separate package. On ``Mac OS`` it is installed by default and is called ``Bonjour``. Apple releases an installer for ``Windows`` that can be found `on Apple's support page <https://support.apple.com/downloads/bonjour-for-windows>`_. On ``Linux``, mDNS is provided by `avahi <https://github.com/lathiat/avahi>`_ and is usually installed by default.
 
 mDNS Properties
 ^^^^^^^^^^^^^^^

docs/en/api-reference/protocols/modbus.rst

@@ -4,7 +4,7 @@ ESP-Modbus
 The Espressif ESP-Modbus Library (esp-modbus) supports Modbus communication in the networks based on RS485, Wi-Fi, Ethernet interfaces.
 The ESP-IDF component `freemodbus` has been moved from ESP-IDF since version v5.0 to a separate repository:
 
-* `ESP-Modbus component on GitHub <https://www.github.com/espressif/esp-modbus>`__
+* `ESP-Modbus component on GitHub <https://github.com/espressif/esp-modbus>`__
 
 Hosted Documentation
 --------------------

docs/en/api-reference/system/console.rst

@@ -127,7 +127,7 @@ Examples:
 Argument parsing
 ----------------
 
-For argument parsing, ``console`` component includes `argtable3 <http://www.argtable.org/>`_ library. Please see `tutorial <http://www.argtable.org/tutorial/>`_ for an introduction to `argtable3 <http://www.argtable.org/>`_. Github repository also includes `examples <https://github.com/argtable/argtable3/tree/master/examples>`_.
+For argument parsing, ``console`` component includes `argtable3 <https://www.argtable.org/>`_ library. Please see `tutorial <https://www.argtable.org/tutorial/>`_ for an introduction to `argtable3 <https://www.argtable.org/>`_. Github repository also includes `examples <https://github.com/argtable/argtable3/tree/master/examples>`_.
 
 
 Command registration and dispatching

docs/en/api-reference/system/mem_alloc.rst

@@ -151,12 +151,14 @@ Implementation Notes
 
 Knowledge about the regions of memory in the chip comes from the "soc" component, which contains memory layout information for the chip, and the different capabilities of each region. Each region's capabilities are prioritised, so that (for example) dedicated DRAM and IRAM regions will be used for allocations ahead of the more versatile D/IRAM regions.
 
-Each contiguous region of memory contains its own memory heap. The heaps are created using the `multi_heap <API Reference - Multi Heap API>`_ functionality. multi_heap allows any contiguous region of memory to be used as a heap.
+Each contiguous region of memory contains its own memory heap. The heaps are created using the :ref:`multi_heap <multi-heap>` functionality. multi_heap allows any contiguous region of memory to be used as a heap.
 
 The heap capabilities allocator uses knowledge of the memory regions to initialize each individual heap. Allocation functions in the heap capabilities API will find the most appropriate heap for the allocation (based on desired capabilities, available space, and preferences for each region's use) and then calling :cpp:func:`multi_heap_malloc` for the heap situated in that particular region.
 
 Calling ``free()`` involves finding the particular heap corresponding to the freed address, and then calling :cpp:func:`multi_heap_free` on that particular multi_heap instance.
 
+.. _multi-heap:
+
 API Reference - Multi Heap API
 ------------------------------
 

docs/en/api-reference/template.rst

@@ -25,7 +25,7 @@ Overview
 
     1. Provide overview where and how this API may be used.
     2. Where applicable include code snippets to illustrate functionality of particular functions.
-    3. To distinguish between sections, use the following `heading levels <http://www.sphinx-doc.org/en/stable/rest.html#sections>`_:
+    3. To distinguish between sections, use the following `heading levels <https://www.sphinx-doc.org/en/master/usage/restructuredtext/basics.html#sections>`_:
 
         * ``#`` with overline, for parts
         * ``*`` with overline, for chapters