Merge bitcoin#12933: doc: Refine header include policy

fad0fc3 Refine travis check for duplicate includes (MarcoFalke)

Pull request description:

  Since there is no harm in having "duplicate" includes and it makes it obvious what are the dependencies of each file, without having to do static analysis or jumping between files, I'd suggest to revert the travis check for duplicate includes.

  Generally, I think that enforcing minor style preferences should not be done via travis. The cost of maintaining and the burden on other developers is too high. C.f discussion in bitcoin#10973 (comment)

Tree-SHA512: 97ab0e769d457ccfb873fff6c99613f8b944cd7ef95bfdccb0e1bbe8f5df1f16548c658fa03af42516f806546e75646d338a061e7b057619490235d311ca21f1

contrib/devtools/lint-includes.sh

@@ -19,17 +19,6 @@ for HEADER_FILE in $(filter_suffix h); do
         echo
         EXIT_CODE=1
     fi
-    CPP_FILE=${HEADER_FILE/%\.h/.cpp}
-    if [[ ! -e $CPP_FILE ]]; then
-        continue
-    fi
-    DUPLICATE_INCLUDES_IN_HEADER_AND_CPP_FILES=$(grep -hE "^#include " <(sort -u < "${HEADER_FILE}") <(sort -u < "${CPP_FILE}") | grep -E "^#include " | sort | uniq -d)
-    if [[ ${DUPLICATE_INCLUDES_IN_HEADER_AND_CPP_FILES} != "" ]]; then
-        echo "Include(s) from ${HEADER_FILE} duplicated in ${CPP_FILE}:"
-        echo "${DUPLICATE_INCLUDES_IN_HEADER_AND_CPP_FILES}"
-        echo
-        EXIT_CODE=1
-    fi
 done
 for CPP_FILE in $(filter_suffix cpp); do
     DUPLICATE_INCLUDES_IN_CPP_FILE=$(grep -E "^#include " < "${CPP_FILE}" | sort | uniq -d)

doc/developer-notes.md

@@ -569,8 +569,7 @@ Source code organization
   - *Rationale*: Shorter and simpler header files are easier to read, and reduce compile time
 
 - Every `.cpp` and `.h` file should `#include` every header file it directly uses classes, functions or other
-  definitions from, even if those headers are already included indirectly through other headers. One exception
-  is that a `.cpp` file does not need to re-include the includes already included in its corresponding `.h` file.
+  definitions from, even if those headers are already included indirectly through other headers.
 
   - *Rationale*: Excluding headers because they are already indirectly included results in compilation
     failures when those indirect dependencies change. Furthermore, it obscures what the real code