Adjust the refcounts to avoid Mutex leak

[shinrich]

This PR addresses issue #5777.

After talking with @traeak a few days ago, staring at the code for a day, and talking with @SolidWallOfCode, I think I understand what is going on. The problem is that we are treating ProxyMutex objects as referenced counted smart pointers from within the INKContInternal objects, but we are also treating them as not-smart pointers via the C Plugin interface TSMutexCreate, TSMutexLock, TSMutexUnlock, and TSMutexDestroy.

@traeak identified the commit from PR #4926 as the cause of the leak. That PR was cleaning up the various mutex lock/unlock methods and added refcount increment decrement to TSMutexCreate/Destroy to try to make things uniformly reference counted. However, with that change, the ProxyMutex's created by TSMutexCreate and passed to TSContCreate would never be deleted, because the stand-alone TSMutexDestroy was never called to decrement the last reference count.

This PR

• Removes the reference count increment/decrement from TSMutexCreate/Destroy. Returning to the behavior from before PR Make mutex lock routines deal with null mutex and general clean up. #4926
• Adds non-smart pointer versions of Mutex_lock, Mutex_unlock, and Mutex_trylock, which also reverts some of the cleanup from PR Make mutex lock routines deal with null mutex and general clean up. #4926. Without this change calls to TSMutexLock/Unlock from the plugin would delete the ProxyMutex on return from the mutex call because the smart pointer reference count would go to 0. These crashes would exhibit in autests for traffic_dump and lua_watermark.

This is not the optimal solution, but good enough for release 9. A more consistent solution would likely require more changes in plugin code. I will leave discussion for that to another thread.

[traeak]

Ran a battery of tests against this fix including tests with the slice plugin and remap_stats plugin. The fixes look good and consistent. I think I may have found a leak in remap_stats :(

[calavera]

I ran our plugin with this, and I don't see any leak.

[oknet]

looks good.

It just pulls back the non-smart pointer versions of Mutex_lock, Mutex_unlock, and Mutex_trylock which are used in InkAPI.

[zwoop]

Cherry-picked to v9.0.x branch.