Fix for pdfmaker.js datasrc processing (DESY)

[drfho]

Hello @zmsdev,
Function _blobfields.createBlobField() may use the wrong py3 module to transform a string/base64 based file stream into a file? Please revise the change history after migrating the function from py2 to py3:

1. 5f43688#diff-6500a5d0b2a201f9c6d07c46ed55d1b067e59062237c71d91caab8182bed3031
2. adc3388#diff-6500a5d0b2a201f9c6d07c46ed55d1b067e59062237c71d91caab8182bed3031

Using pdfmake.js does not result in a file-object using a sequence of bytes(data,'utf-8') and io.BytesIO( data), but it works with io.StringIO ( data)

Screenshots;

[drfho]

okay, removing this kind of "preemptive" str-handling was a good idea. So surprises in the transformation cascade are reduced. This works fine now.

Another Trap:
with latest Zope 5+ using pdfmake.js to create PDF. Big images or several images may result in a data-stream which is too big to get processed. After introdicing this PR
zopefoundation/Zope#1094
Zope now works with an arbitray form data size limitations:

https://github.com/zopefoundation/Zope/blob/345d656557bfc414f70b92637fef33dde747a97d/src/ZPublisher/HTTPRequest.py#L54-L58

Actually 1Mb (2**20 byte) is not much for a PDF file with images; so FORM_MEMORY_LIMIT should set at least to 2**22 = 4Mb

FORM_MEMORY_LIMIT = 2**20

FORM_MEMORY_LIMIT = 2**30

[drfho]

Opened the FORM_MEMORY_LIMIT issue at Zope:
zopefoundation/Zope#1141