Silence false positive memory leaks reported by MSVC debug CRT

[scottslacksmith]

There are few Issues (e.g. #624 , #692 and #757) requesting a "memory leak" fix for MSVC debug builds. In fact these are not true memory leaks but false positives due to limitations of MSVC's lightweight memory leak detection mechanism (see below). But I think this is missing the real point that #624 , #692 and #757 are trying to solve. It's highly desirable that all false positive leaks be either fixed or silenced otherwise it becomes impractical to identify real leaks using MSVC's leak report. I normally endeavour to fix all false positive leaks (e.g. as suggested by #757) but in this instance silencing is the best solution as it's impossible to test that the destructors aren't called too early for all possible build configuration that may exist in the wild.

As background, MSVC debug CRT can only detect if a memory allocation is missing a matching deallocation. Note MSVC debug CRT is always tracking memory allocations however the memory leak report is disabled by default. As you can’t avoid paying for its cost, you may as well use it. The memory leak report can be enabled by calling the following function
_CrtSetDbgFlag(_CrtSetDbgFlag(_CRTDBG_REPORT_FLAG) | _CRTDBG_LEAK_CHECK_DF);
anywhere before exiting main.
For example, the following are the false positive leaks reported by gtest_prod_test.exe before this change;

Detected memory leaks!
Dumping objects ->
{750} normal block at 0x015DF938, 8 bytes long.
Data: <  ]     > 00 F9 5D 01 00 00 00 00
{749} normal block at 0x015DEE60, 32 bytes long.
Data: <` ] ` ] ` ]     > 60 EE 5D 01 60 EE 5D 01 60 EE 5D 01 01 01 CD CD
{748} normal block at 0x015DF900, 12 bytes long.
Data: <8 ] ` ]     > 38 F9 5D 01 60 EE 5D 01 00 00 00 00
{747} normal block at 0x015DA0F8, 24 bytes long.
Data: <                > FF FF FF FF FF FF FF FF 00 00 00 00 00 00 00 00
Object dump complete.

As you can see from above it’s not easy to identify which leaks are false
positives or not. Consequently, if false positive leaks are not fixed or
silenced, then it becomes impractical to identify real memory leaks.

[scottslacksmith]

A possibly more elegant solution is to defined an immortal pointer. For example

template<typename T>
struct immortal_delete {
  void operator()(T*) const noexcept {}
};

// Is an unique_ptr where the held object can never be destroyed.
// The motivation is to self-document objects that are intentionally 
// never destroy/deallocated because they are reachable for the entire
// lifetime of an app.
template<typename T>
using immortal_unique_ptr = std::unique_ptr<T, immortal_delete<T>>;

template<class T, class... Args> 
immortal_unique_ptr<T> make_immortal_unique(Args&&... args)
{
  MemoryIsNotDeallocated memoryIsNotDeallocated;
  return (immortal_unique_ptr<T>(new T(std::forward<Args>(args)...)));
}

(reusing std::unique_ptr may not work if an implementation's debug version of std::unique_ptr's dtor resets the naked pointer to nullptr to uncover hidden bugs, in which case we would be necessary to create a new immortal_unique_ptr class that mimics unique_ptr)

In which case

  // Returns map of thread local instances.
  static ThreadIdToThreadLocals* GetThreadLocalsMapLocked() {
    mutex_.AssertHeld();
    static ThreadIdToThreadLocals* map = new ThreadIdToThreadLocals;
    return map;
  }

becomes

  // Returns map of thread local instances.
  static ThreadIdToThreadLocals* GetThreadLocalsMapLocked() {
    mutex_.AssertHeld();
    static immortal_unique_ptr<ThreadIdToThreadLocals> map = immortal_unique_ptr<ThreadIdToThreadLocals>();
    return map.get();
  }

The advantage is that we clearly document which object constructions are intentionally never destroyed. For example, it could handy in a different context where an app is constantly loading and unloading .so/.dll plugins, in which case I believe a function static like
static ThreadIdToThreadLocals* map = new ThreadIdToThreadLocals;
could be classified as a true memory leak.

[gennadiycivil]

Apologies for not getting to this sooner. As a preparation for 1.8.x release I am cleaning up older PR that are in CI failed status and/or have merge conflicts.
Please submit a new PR if you think this is still important/relevant.