Don't decrypt the /Contents of signature dictionaries - #22335

In an encrypted PDF, the parser decrypts every string, including the /Contents of signature dictionaries. That value isn't encrypted, though: the signature is written into the space reserved for it only after the file has been encrypted. As a result, the pkcs7 data that getSignatureData returns for an encrypted signed PDF is garbage, and the signature can't be verified.

issue17069.pdf from the test suite is an example. On master, its PKCS#7 data starts with c9 1a 1e 12, and openssl cms -verify -binary -inform DER -noverify can't parse it ("wrong tag"). The same happens with qpdf's minimal-signed-restricted.pdf, which is signed by Adobe Acrobat Sign. With this patch, the data of both files starts with the DER header 30 82, and openssl reports "CMS Verification successful" against the signed byte ranges that getSignatureData returns.

PDFBox and PDFium don't decrypt this value either. With this patch, getSignatureData reads the /Contents value of an encrypted PDF from the file, in the gap between the two /ByteRange spans, where it's stored unencrypted, and falls back to the parsed value if the gap doesn't hold a single string. The parser, the writer and unencrypted documents are unchanged.

The new api_spec.js test reads the signature of issue17069.pdf and checks the length and the DER header of its PKCS#7 data. It fails without this change.