fix bug #657. RPC module frees the msg body while other threads still access that struct to cause the SIGSEGV error.

1. potential data race in `taosProcessMonitorTimer`:
the issue does not exist at present because there's only one scheduler
thread, which means there's no cocurrent calls to this function for a
same `pMonitor`. but if more scheduler threads are created later,
there's a data race issue in rare case. as threads number can be
easily increased by increase the value of `taosTmrThreads`, it is very
unlikely that the developer could realize this function need to be
revised together. that's why i say it is a 'potential' issue.

this issue happens in below scenario:
a. scheduler thread1: `if (pSet)` is true and new timer is installed by
`taosTmrReset`;
b. scheduler thread1: `if (pMonitor->pSet == NULL)` is true but
`taosTmrStopA` is blocked, either by the mutex of the timer or os thread
scheduler.
c. timer thread: 200ms elapse, new call to `taosProcessMonitorTimer` is
initialized in scheduler thread2;
d. scheduler thread2: `if (pMonitor->pTimer != tmrId)` is false;
e. scheduler thread1: unblocked, stops timer and frees `pMonitor`;
f. scheduler thread2: unexpected behavior because `pMonitor` is not
valid any more.

because the result of this issue is crash or worse, i suggest to fix it
though the possibility of all the conditions are met is very very low.

2. `pthread_attr_t` related issues: per manual, an initialized
`pthread_attr_t` can be reused, should be destroyed, and the behavior of
re-init it is undefined. this issue exist in other modules also.

3. memory leaks;

4. improve failure case handling of `taosInitUdpConnection`;

5. typo

Signed-off-by: Nsiddontang <siddontang@gmail.com>