DRTVWR-476: Introduce LLEventMailDrop::discard() (instead of flush()).

Overriding virtual LLEventPump::flush() for the semantic of discarding
LLEventMailDrop's queued events turns out not to be such a great idea, because
LLEventPumps::flush(), which calls every registered LLEventPump's flush()
method, is called every mainloop tick. The first time we hit a use case in
which we expected LLEventMailDrop to hold queued events across a mainloop tick,
we were baffled that they were never delivered.

Moving that logic to a separate method specific to LLEventMailDrop resolves
that problem. Naming it discard() clarifies its intended functionality.

indra/llcommon/llevents.cpp

@@ -602,6 +602,11 @@ LLBoundListener LLEventMailDrop::listen_impl(const std::string& name,
     return LLEventStream::listen_impl(name, listener, after, before);
 }
 
+void LLEventMailDrop::discard()
+{
+    mEventHistory.clear();
+    LLEventStream::flush();
+}
 
 /*****************************************************************************
 *   LLEventQueue
@@ -621,8 +626,8 @@ bool LLEventQueue::post(const LLSD& event)
 
 void LLEventQueue::flush()
 {
-	if(!mSignal) return;
-		
+    if(!mSignal) return;
+
     // Consider the case when a given listener on this LLEventQueue posts yet
     // another event on the same queue. If we loop over mEventQueue directly,
     // we'll end up processing all those events during the same flush() call

indra/llcommon/llevents.h

@@ -610,7 +610,8 @@ public:
     virtual bool post(const LLSD& event) override;
     
     /// Remove any history stored in the mail drop.
-    virtual void flush() override { mEventHistory.clear(); LLEventStream::flush(); };
+    void discard();
+
 protected:
     virtual LLBoundListener listen_impl(const std::string& name, const LLEventListener&,
                                         const NameList& after,

indra/newview/llvoicevivox.cpp

@@ -1474,7 +1474,7 @@ bool LLVivoxVoiceClient::addAndJoinSession(const sessionStatePtr_t &nextSession)
     // We are about to start a whole new session.  Anything that MIGHT still be in our 
     // maildrop is going to be stale and cause us much wailing and gnashing of teeth.  
     // Just flush it all out and start new.
-    mVivoxPump.flush();
+    mVivoxPump.discard();
 
     // It appears that I need to wait for BOTH the SessionGroup.AddSession response and the SessionStateChangeEvent with state 4
     // before continuing from this state.  They can happen in either order, and if I don't wait for both, things can get stuck.