Fixes ClusterFuzz issues67399 and55299

Issue 67399: gitpython: Fuzzing build failure

Since: 2024-03-11

The Problem

The pre-installed version ofpip (19.2.3) was outdated and unable to parse thepyproject.toml syntax during the install step inbuild.sh causing the script to error out and crash.

The Solution

Upgradingpip to the latest version in the project image resolves the issue and allows the installation to complete.

Issue 55299: gitpython: Coverage build failure

Since: 2023-01-21

The Problem

(my hypothesis at least)

I believe the root of the issue here was caused by fuzzer initialization and execution taking too long for the actual run to generate a meaningful corpus. I suspect this because:

• Thebuild log posted in the CF issue shows the coverage build fails after trying to unzip the corpus archives and warning the zipfiles are empty.
• I downloaded a backup of the corpus zips to confirm and they are in fact empty.
• This project has a deep dependency graph which caused the call to
  atheris.instrament_all() to instrument 4,000+ functions before the fuzzer execution could begin which was causing a significant delay (on my local machine, at least) before actual test execution would start.

The Solution(-ish)

The commit message on908ba9c should sum it up, but the TL;DR is I reduced the scope of instrumented functions to align closer with the APIs being fuzzed and added dictionaries and seed corpra which provided promising results locally.

fuzz_tree.py is still slow as far as average_exec_per_sec, but startup is quicker and with the seed data it gets close to its coverage depth fairly quickly as well.

• I believe this will fix the OSS-Fuzz coverage build at least.
• but I suspect the Introspector build will continue to timeout because I couldn't figure out how to get pycg to play nicely with the dependency graph
  • (I think there's a circular dependency it gets stuck on, but that's a problem for another day.)