src/send_kcidb.py: Extract patchset hash from patchwork metadata

[yurinnick]

Extract head patch hash from patchwork data if it's available. This will allow us to store and populate patch-specific test results and link them to Patchwork.

Fixes kernelci/kernelci-api#307

[spbnick]

The KCIDB patchset hash is described here: https://github.com/kernelci/kcidb-io/blob/4691cd7e477083268e69e401fa6d0b6e07f76648/kcidb_io/schema/v04_02.py#L237-L256

However, there's a complication WRT Patchwork. IIRC, it modifies the mbox'es normally used as the patches to add its own tracking information, so just hashing them produces a different hash after every update. The CKI project solution was to strip everything but patches themselves from them to keep it stable.

[gctucker]

This one will depend on the rest of the changes to have been merged first, as if the patchset data is stored differently then it'll need to be updated accordingly. I think we can keep it open and rework it later on if needed.

[gctucker]

Adding the staging-skip label to not deploy it on staging yet until other parts of the code are ready (storing patchset information in kernel revision / checkout data etc.).

[yurinnick]

@spbnick Patchwork has it's own implementation of patch hashing (hasher.py), which I believe does the trick of generating persistent hash of patch content.

However, it uses sha1 instead of sha256 and does some additional patch parsing. Should we use their implementation for patch hashing, or it's better to ignore it and rehash patches on KernelCi or kernelci-patchwork-webhook side?

[gctucker]

I guess we should first complete the discussion on kernelci/kernelci-api#307 about the schema changes now we know the patch information needs to be in Node.Revision data model? Then once we have a clearer idea of how things will look like on the API side the rest should follow more naturally.