fix(docs): fix more broken links still pointing to .rst files [backport 1.18] (#6797)

Backport 599ac2e from #6790 to 1.18.

## Motivation

The docs still point to some `.rst` files, causing a 404 as mentioned in
[this issue](#6788)

## Checklist

- [X] Change(s) are motivated and described in the PR description.
- [X] Testing strategy is described if automated tests are not included
in the PR.
- [X] Risk is outlined (performance impact, potential for breakage,
maintainability, etc).
- [X] Change is maintainable (easy to change, telemetry, documentation).
- [X] [Library release note
guidelines](https://ddtrace.readthedocs.io/en/stable/releasenotes.html)
are followed. If no release note is required, add label
`changelog/no-changelog`.
- [X] Documentation is included (in-code, generated user docs, [public
corp docs](https://github.com/DataDog/documentation/)).
- [X] Backport labels are set (if
[applicable](https://ddtrace.readthedocs.io/en/latest/contributing.html#backporting))

## Reviewer Checklist

- [x] Title is accurate.
- [x] No unnecessary changes are introduced.
- [x] Description motivates each change.
- [x] Avoids breaking
[API](https://ddtrace.readthedocs.io/en/stable/versioning.html#interfaces)
changes unless absolutely necessary.
- [x] Testing strategy adequately addresses listed risk(s).
- [x] Change is maintainable (easy to change, telemetry, documentation).
- [x] Release note makes sense to a user of the library.
- [x] Reviewer has explicitly acknowledged and discussed the performance
implications of this PR as reported in the benchmarks PR comment.
- [x] Backport labels are set in a manner that is consistent with the
[release branch maintenance
policy](https://ddtrace.readthedocs.io/en/latest/contributing.html#backporting)
- [x] If this PR touches code that signs or publishes builds or
packages, or handles credentials of any kind, I've requested a review
from `@DataDog/security-design-and-guidance`.
- [x] This PR doesn't touch any of that.

Co-authored-by: Eric Navarro <[email protected]>

Author: github-actions[bot]

docs/contributing-integrations.rst

@@ -1,3 +1,5 @@
+.. _integration_guidelines:
+
 ===========================
 How To Write an Integration
 ===========================
@@ -29,7 +31,7 @@ Your development process might look like this:
 
   - Write the integration (see more on this below).
 
-  - Open a `pull request <contributing.rst#change-process>`_ containing your changes.
+  - Open a :ref:`pull request<change_process>` containing your changes.
 
 All integrations live in ``ddtrace/contrib/`` and contain at least two files,
 ``__init__.py`` and ``patch.py``. A skeleton integration is available under

docs/contributing-testing.rst

@@ -1,3 +1,5 @@
+.. _testing_guidelines:
+
 Testing
 =======
 

docs/contributing.rst

@@ -15,6 +15,8 @@ and `docker-compose <https://www.docker.com/products/docker-compose>`_.
 
 Thanks for working with us!
 
+.. _change_process:
+
 Change Process
 ==============
 
@@ -99,15 +101,15 @@ Tests
 -----
 
 If your change touches Python code, it should probably include at least one test. See the
-`testing guidelines <contributing-testing.rst>`_ for details.
+:ref:`testing guidelines<testing_guidelines>` for details.
 
 Documentation
 -------------
 
 Pull requests implementing new features should include documentation for those features. The audience for this
 documentation is the public population of library users. The Products and Core logic are documented alongside
 this document, in the ``docs`` directory. The documentation for each Integration is contained in a docstring
-in that integration's ``__init__.py`` file. See `this page <contributing-integrations.rst>`_ for more information
+in that integration's ``__init__.py`` file. See :ref:`this page<integration_guidelines>` for more information
 on writing documentation for Integrations.
 
 Logging

docs/releasenotes.rst

@@ -11,7 +11,7 @@ with the library.
 
 A release note is **required** if a PR is user-impacting, or if it meets any of the following conditions:
 
-* `Breaking change to the public API <versioning.rst#release-versions>`_
+* :ref:`Breaking change to the public API<versioning_release>`
 * New feature
 * Bug fix
 * Deprecations