[geary/wip/double-content-type-724329] Hack around double Content-Type header

[Charles Lindsay <clindsay src gnome org>]

commit a611b6ab0810c4d745f07d7dae6d1dae7b4fa82e
Author: Charles Lindsay <chaz yorba org>
Date:   Tue Feb 18 12:38:27 2014 -0800

    Hack around double Content-Type header
    
    GMime has a bug where if you remove a header from a freshly parsed
    message, it'll add a second Content-Type header.

 src/engine/rfc822/rfc822-message.vala |   13 +++++++++++++
 1 files changed, 13 insertions(+), 0 deletions(-)
---
diff --git a/src/engine/rfc822/rfc822-message.vala b/src/engine/rfc822/rfc822-message.vala
index 13c5746..3cfc1e6 100644
--- a/src/engine/rfc822/rfc822-message.vala
+++ b/src/engine/rfc822/rfc822-message.vala
@@ -211,8 +211,21 @@ public class Geary.RFC822.Message : BaseObject {
             error("Error creating a memory buffer from a message: %s", e.message);
         }
         
+        // GMime also drops the ball for the *new* message.  When it comes out of the GMime
+        // Parser, its "mime part" somehow isn't realizing it has a Content-Type header
+        // already, so whenever you manipulate the headers, it adds a duplicate one.  This
+        // odd looking hack ensures that any header manipulation is done while the "mime
+        // part" is an empty object, and when we re-set the "mime part", there's only the
+        // one Content-Type header.  In other words, this hack prevents the duplicate
+        // header, somehow.
+        GMime.Object original_mime_part = message.get_mime_part();
+        GMime.Message empty = new GMime.Message(true);
+        message.set_mime_part(empty.get_mime_part());
+        
         message.remove_header(HEADER_BCC);
         bcc = null;
+        
+        message.set_mime_part(original_mime_part);
     }
     
     private GMime.Object? coalesce_parts(Gee.List<GMime.Object> parts, string subtype) {