Fix data race reported by ThreadSanitizer in caching pool

[nanangizz]

There is a report of data race:

 WARNING: ThreadSanitizer: data race (pid=13933)
  Write of size 8 at 0x726800000680 by main thread (mutexes: read M0):
    #0 cpool_on_block_alloc
    #1 default_block_alloc
    #2 pj_pool_create_block
    #3 pj_pool_allocate_find

  Previous write of size 8 at 0x726800000680 by thread T4 (mutexes: write M1, write M2):
    #0 cpool_on_block_free
    #1 default_block_free
    #2 reset_pool
    #3 pj_pool_destroy_int

After investigation, cpool_on_block_alloc() & cpool_on_block_free() are only used for updating fields cp.used_size & cp.peak_used_size which are for informational/logging purpose only. While updated without mutex protection, the information is potentially inaccurate. So I think deprecating those fields & the caching pool callbacks is safe and is able to fix the data race issue.

Thanks to Taisto Qvist for the report.

[sauwming]

They are still used in:

• unit tests such as pjsip-perf.c and pjsip/src/test/test.c
• pjturn-srv/main.c
  Although mostly for logging purposes only.

[nanangizz]

Ah right! Then I guess our options:

• change caching pool's mutex type to recursive mutex, but it may have some impact on performance (e.g: here), affected functions: pj_pool_create/release() (less impact because less frequently used?), pj_pool_alloc()/reset() (more impact, depends on initial & growing capacity). Perhaps avoid this approach as the fields are for logging purpose.
• leave it as is with possibility of data race, which may reduce accuracy of those fields, and trigger semi 'false alarm' on analyzing tools.
• use pj_mutex_try_lock(), when fails keep going without lock, assuming the failure is caused by having been locked by upstream/caller, e.g: pj_pool_create/release()
• ...?

[sauwming]

since the usage is mostly for logging and tests only, I suppose just comment/remove the code that use the deprecated fields?