Upgrade zetacomponents/base and zetacomponents/mail

[mfb]

Overview

CiviCRM contains some pretty ancient versions of zetacomponents/base and zetacomponents/mail

Before

Using the 1.7 branch of zetacomponents/base and zetacomponents/mail

After

• Upgrade zetacomponents/base to 1.9 branch and zetacomponents/mail to 1.8 branch (bug fixes and PHP 7.3 compatibility).
• Handle the case of email body instance-of ezcMailFile when parsing emails.
• Fix an incorrectly-encoded test fixture email (there now seems to be more strict decoding of email messages).

Comments

We also need to merge the Civi patches into the forked version of zetacomponents/mail; see civicrm/zetacomponents-mail#4

[civibot]

(Standard links)

• If this is your first pull-request for CiviCRM, please browse CONTRIBUTING.md for information about the development and testing processes.
• If you are reviewing this pull-request, you may wish to consult the test sites and the Review Standards (long template, short template).

[mlutfy]

jenkins, test this please

[mfb]

ok we need to resolve this: Fatal error: Call to undefined method ezcMailFile::getParts() in /home/jenkins/bknix-dfl/build/core-13799-7jszs/sites/all/modules/civicrm/CRM/Utils/Mail/EmailProcessor.php on line 299

[mfb]

Found that a test fixture email had invalid quoted printable encoding, presumably from someone scrubbing identifying URL parameters by hand.

[mfb]

By the way, I noticed that this upgrade resolves some fatal errors on PHP 7.3, so I think it's high priority to get this in.

[mfb]

It looks like when a parsed email has a simple non-multipart body, it was previously an ezcMailText object, and is now an ezcMailFile object.

The library stores file parts in the system temp directory, and uses a shutdown callback to clean them up afterwards. They are stored in a directory based on process ID, for example for PID 4735, one email might have its body at /tmp/4735-1/filename and another might be /tmp/4735-3/filename.

As far as I can tell I am successfully working around it, by reading the body contents back from disk.

[eileenmcnaughton]

My big worry was that we still need to support 5.6 however from their travis file it seems they do https://github.com/zetacomponents/Base/blob/master/.travis.yml

We also know we have some test cover on the component - as those tests failed triggering the related changes

I'm going to merge this

[mfb]

@eileenmcnaughton we also need to merge civicrm/zetacomponents-mail#4 before this one. Otherwise the Civi patches won't be included.