revert commit ec0d05a

dialog variables might be binary, therefore strlen should not be used
Add the SIP-wise determined "next_hop" field to ucontact_t

* based on Path -> Received -> Contact (decreasing priorities)
* URIs are parsed only at contact creation
* useful for the nathelper SIP pinging routine and domain-based lookups
* compatible with all DB modes, no extra DB columns required
Add the "remove" script function to the registrar module

* remove(domain, AOR[, target]])
* explicitly remove	contacts behind specific addresses-of-record
* may delete contacts by Contact URI or by domain
* domains are resolved before they are matched
Fix the DB representation of message flags in the acc module

* storing flags as strings rather than bitmasks prevents flag conflicts
  when doing flag modifications in the script, then restarting the proxy
* similar usrloc issue was fixed in commit 98b6b0437
uac_registrant: re-register with expires value imposed by the registrar
Ignore all cscope database files
Fixed bogus warning because of variables not being reset.
Reported by Jeff Pyle, part of fixing issue #126.
Merge pull request #133 from shimaore/add-callid-to-ul_mi

Add `callid` field to information returned by the `ul` module's MI.
Merge pull request #131 from dsandras/ds-pua-mi-warning-fix

Fixes bug where a refreshed PUBLISH request triggers an error message.(cherry picked from commit ded0559c527f30181e9bbd494f0e63b048059108)
Merge pull request #122 from dsandras/ds-fix-dialog-info-entity

This patch fixes the entity URI in XML documents to contain "sip:".(cherry picked from commit 377e7574d411aa974cf469d6df18b6213b43a31f)
Fixed residential example when using presence
Load xcap module, presence_xml depends on it
Updated DB schema to reflect the changes in the DR module (adding persistency for carrier/gateway's state and sockets for gateways)
STEP 3 - flushing changes in GW/CARRIER's state back to DB (periodically and at shutdown) ; preserve the state of GWs/CARRIERs during reload.
pua: set db_flag to UPDATEDB_FLAG only if there was a previous update (NO_UPDATEDB_FLAG)
 - in case of a server restart, if the db_flag went from INSERTDB_FLAG to UPDATEDB_FLAG
   the record will be lost because the record is marked as to be updated,
   and since there's no record in the db, the update will fail.
 - if the db_flag is INSERTDB_FLAG, any updates should leave the flag as is and this
   will cause the new record to be properly inserted (and not updated) into the db.
Merge branch 'master' into production