Flush chttpd_db monitor refs on demonitor

This ensures that the coordinator process flushes on demonitoring of the
attachment refs in chttpd_db. The problem here is that it's possible to
receive a 'DOWN' message for the monitor ref that is not receive'ed,
causing it to stick around in the coordinator message queue while the
next http request is handled. The pending message will not become
apparent until the next fabric call is invoked, as fabric expects to
have full access to all messages in the calling process, an expectation
which is violated by the pending message and causes a case clause crash
in the fabric receive message callbacks.

I noticed this during eunit runs with stubbed attachment handles that
generate an immediate noproc message on the monitor call. Normal
operations should not result in an immediate noproc result on monitoring
the attachment process, however, any failure that causes the attachment
process to fail between acquisition of the refs and the demonitor calls
will induce this bug, causing the next http request handled by the
particular chttpd coordinator pool processs to fail on whatever next
fabric call is made.

src/chttpd/src/chttpd_db.erl

@@ -2249,7 +2249,7 @@ monitor_attachments(Att) ->
     monitor_attachments([Att]).
 
 demonitor_refs(Refs) when is_list(Refs) ->
-    [demonitor(Ref) || Ref <- Refs].
+    [demonitor(Ref, [flush]) || Ref <- Refs].
 
 % Return attachments which are not stubs
 non_stubbed_attachments(Atts) when is_list(Atts) ->