Non-bucket specific stats (e.g. ExecutorPool::doTaskQStat) do not correctly account freed memory

Background

Non-bucket specific stat groups, such as ExecutorPool::doTaskQStat (correctly) switch away from the current engine before generating stats - we shouldn't account any temporary heap usage to any particular bucket.

The process of generating these stats requires the creation of an empty std::unordered_map to pass as an empty Labels object. On Windows, this requires a heap allocation (but apparently no on macOS / Linux) - this is important later...

The addStat callback used to actually emit the stat uses NonBucketAllocationGuard to temporary switch away from the current ep-engine instance when calling down to daemon (again, to correctly account memory), which switches back to the current ep-engine instance when destroyed.

Problem

The combination of the two previous operations means on Windows there is a call to delete the heap memory for the empty std::unordered_map, which occurs after NonBucketAllocationGuard has been destroyed - and hence current arena has incorrectly switched back to the current ep-engine instance.

This results in the temporary heap memory (originally allocated against the global arena) being counted (subtracted) from the current ep-engine arena - resulting in mem_used being slightly lower (128 measured per stat call) than it should be.

Affected stat groups:

• "workload"
• "tasks"

I don't believe the affected stat group(s) are normally called outside cbcollect_info, so the real-world impact of this should be minimal, but if a Windows cluster did have the the taskQ stat group requested repeatedly it could cause incorrect mem_used values.