Improved handling of Replicator close under unforeseen circumstances

There are couple of instances when the replicator.close() does not return in a timely fashion or does not return at all, causing apps to get into a state from which it is hard to recover
1) It is quite common for replicator to get stuck in a "busy state" (something on server end could trigger this). When this happens, apps cannot do much with the replicator except to close the replicator, which they cannot do because the replicator is stuck in busy state. As a consequence , database cannot be closed in a timely fashion either (from app perspective, it "never returns")

2) If there is a network disconnect from server side or if the server is unreachable for some reason, a close on the replicator takes a long time from apps perspective - It has been indicated that even order of seconds is deemed to be too long for app to wait for things to shut down. 

This task is to look into enhancements to improving the handling of replicator close

• Including a configurable timeout on the close API and to "give up" after ?
• What is the implication of giving up
  • Replicator should be force closed
  • Apps should be able to close db if needed

On a related note,on replicator busy case,  there is also suggestions to have a configurable timeout to give up on  "busy" state of replicator. This would be the case when replicator is in busy state but the progress indicator shows extended period of inactivity. Apps have implement their own "timeout" today but run into the issues outlined earlier trying to get out of it. 

CC Jens Alfke, Jim Borden, Pasin Suriyentrakorn, Daniel Petersen