osTicket/osTicket-1.8 — pull request #861 by greezybacon (2014-05-06 19:08:17+00:00)
Title: Make mail parsing more memory efficient

This patch reduces the memory footprint for parsing large mails by about 37% without increasing the processing time. Processing an example 31MB email with the stock code on the develop branch:
```
$ time php api/pipe.php < ~/75-ce3cd9ada7718705.eml
173636064
php api/pipe.php < ~/75-ce3cd9ada7718705.eml 0.90s user 0.70s system 96% cpu 1.662 total
```
(peak memory usage is the raw number (166 MiB)). And with the new code:
```
$ time php api/pipe.php < ~/75-ce3cd9ada7718705.eml
109242760
php api/pipe.php < ~/75-ce3cd9ada7718705.eml 1.23s user 0.29s system 96% cpu 1.576 total
```
Memory usage is 104 MiB (about 37% less)

*The timings listed are simply for indicating that the rough processing time for a large mail is about the same. I have not attempted benchmarking to analyze the total impact on processing time*

The main focus is processing the mail in less memory. Since attachments are getting larger and larger, osTicket needs to be more and more memory efficient to be able to process increasingly large emails without requiring special memory tweaks on the server or requiring greater server capacity.

Originally I performed `md5sum` of the sample parsed output; however, the last patch changes the output because the object id # of the HtmlThreadBody in my example email changes because the new code passes around StringView object instances rather than copies of strings. Therefore, I omitted the md5sum checking. I would encourage oversight to ensure that no change in the processing output is incurred by these changes.