Motivation: Debian wants to kill pypdf2 and keep only pypdf (4.3) in
trixie, so we need to be compatible or risk being dropped.

- move all imports from PyPDF2 to odoo.tools.pdf
- add two-ways compatibility shims and aliases

X-original-commit: fddf53c
Part-of: #186301
Related: odoo/enterprise#73330
Signed-off-by: Christophe Monniez (moc) <moc@odoo.com>

In 3.x the PDF header is the header *only*, as it's decoded to a
string. However the mess is mostly unnecessary as since 1.27 pypdf2
always adds a binary comments line when writing out documents. So only
add (or copy) our own garbage when using 1.x.

Also this means our heuristic to detect pdf/a documents makes no
sense, as any pdf document can have a binary sig, but hey...

Also fix _ID handling: in pypdf 3.x it's a property which reads from
the trailer *and* it's automatically copied over by
`clone_reader_document_root`.

X-original-commit: 3dd4a34
Part-of: #186301
Related: odoo/enterprise#73330
Signed-off-by: Christophe Monniez (moc) <moc@odoo.com>

Try to override both old and new API, although for the new version it
might actually be useless as pypdf seems to have added multiple
attachments support circa 3.5? (py-pdf/pypdf#1611)

X-original-commit: c78870c
Part-of: #186301
Related: odoo/enterprise#73330
Signed-off-by: Christophe Monniez (moc) <moc@odoo.com>

The test relied on reader and writer sharing data because
`clone_reader_document_root` would just copy the reference to the root
object, so the writer would immediately impact the reader.

pypdf apparently now copies the document deeply (possibly since 3.2.0
/ py-pdf/pypdf#1520) so this is broken, we need to serialize and
reload the document every time.

X-original-commit: d5807f4
Part-of: #186301
Related: odoo/enterprise#73330
Signed-off-by: Christophe Monniez (moc) <moc@odoo.com>

Next up in the series "`clone_document_from_reader` does stuff now",
`clone_document_from_reader` now properly clones over document
metadata. This means any metadata set *before* the cloning are nuked.

Update the branded writer to write its metadata at the last possible
moment, to ensure it always applies (this might actually be
undesirable as it means callers can't trivially override it anymore).

X-original-commit: e391863
Part-of: #186301
Related: odoo/enterprise#73330
Signed-off-by: Christophe Monniez (moc) <moc@odoo.com>

X-original-commit: 0180654
Part-of: #186301
Related: odoo/enterprise#73330
Signed-off-by: Christophe Monniez (moc) <moc@odoo.com>

`test_download_with_encrypted_pdf` tried to corrupt the PDF by
redirecting the /Encrypt indirect ref to an invalid entry, but it did
so by replacing a hard-coded index. Except the encryption object is
not stored at a fixed offset, where it's stored depends on what pypdf
wants to do with it or what other objects it stores in the file.

Update the replacement to not be completely hard-coded (and also not
assume /Encrypt is at the end of the trailer), and point it back to a
very early object (specifically the first one) which is *extremely*
unlikely to be a valid encryption object (it's very likely to be
either the catalog or the page tree root, though it could also be the
metadata map). This leads pypdf to not find a `/Filter` entry, which
triggers a parse error.

Note: the indirect ref can't be pointed at a nonsensical entry (e.g. 0
or 5479) because in that case pypdf just ignores the ref entirely.

closes #186301

X-original-commit: f37d753
Related: odoo/enterprise#73330
Signed-off-by: Christophe Monniez (moc) <moc@odoo.com>