Add a cluster-reconnection method. when cluster nodes lost all connections, it will attempt to re-connect to target cluster every 2 mins

* database confirm method in different threads, maximum 5 seconds /each check
* close current db connection when error take place.

Sloved a serious problem in heavily client login-logoff. add a rubbish can, hold sockets to be deleted later

Simply add a logger class, with the help of which , develpers can re-direct qDebug(), qWarning(), qCritical() and QFatal(...) outputs to log files , instead of stderr.

Add a auto-join cluster method, as soon as the server node be started, a join-cluster approach will be taken.

Add a thread-quitting cleaning method. when a thread is quitting, its finished signal will be caugth,
so that , db resource class can clean the database connections belongs to this thread one by one.
this method is very important in some situation, such as Qt-concurrent threading, threads will be created, deleted frequently.

* sloved multi-thread db access problem. the databaseresource class has been
improved, for each thread, a thread-owned db connection will be cloned from main
db connection.

a bug caused by m_currentBlock.constData() has been fixed. the pointer returned by this method will be unavaliable when the block has been changed.

There is still a problem in heavily-test.

const QByteArray & type paras, will cause lift cycle problems. using Value-pass instead.
----
QString, QByteArray supports ref-count and auto-delete , also, these classes support
least-copying, deep-copy will only take place, when the data is about to be changed.
so, in singnals and slots, using QString, QByteArray instead of const QString & and const QByteArray & ,
will not cause performance problem.

Each server instance knows exactly how many clients each server currently have.

branch "SMARTLINK" is continous be ok for smartlink project

Delete some fields in message defs, make master branch a "example" branch for study , also as a template for other new branches.

congratulations! a pin version, has been founded. this version, cross-svr cluster has been realized.

When cross-svr network established, servers will exchange their clients uuid info.
wen client log in, local svr will broadcast its uuid to remote svrs, when clients log out,
its uuid will be broadcasted again.

we have only one step left.--the real data hop.