So that all builds have this field populated for consistency.

It's been a year since the current metadata store implementation was
added, so it's fine to now simplify the handling/messaging around
reading older cache versions.

This cleanup will also help with the upcoming switch to the new JSON
metadata store implementation.

GUS-W-19361163.

Co-authored-by: heroku-linguist[bot] <136119646+heroku-linguist[bot]@users.noreply.github.com>

Since:
- Metrics show it to be unused on Heroku.
- It's not supported by the CNB, so removing it improves parity.
- As a feature it's pretty fragile, since unless someone managed
  to keep up with all changes we make to our S3 bucket, builds
  would break every time we bump versions. (And as such, anyone
  using it should be carefully curating the buildpack versions, and
  so can patch the buildpack as part of that repackaging/automation
  process.)

GUS-W-19372843.

Since hash randomisation has been enabled by default since Python 3.3,
so setting `PYTHONHASHSEED=random` is the same as the default, and so
redundant.

See:
- https://docs.python.org/3/using/cmdline.html#envvar-PYTHONHASHSEED
- https://docs.python.org/3/reference/datamodel.html#object.__hash__
- https://docs.python.org/3/whatsnew/3.3.html#builtin-functions-and-types

GUS-W-19372908.

It's not possible to test `bin/report` functionality directly using Hatchet
tests, however, we can dump the raw build metadata store values to at
least test that we're storing the expected keys/values.

This complements the non-Hatchet container CI test that checks that
`bin/report` exits zero.

This has been split out of the upcoming `bin/report` refactor PR to
keep that PR smaller, and to more easily demonstrate the change in
behaviour after that PR.

GUS-W-19384622.

The Node.js buildpack had a set of Bash helper utils for managing a
key-value store of metadata, that could be added to during the build,
and then output when bin/report was run. When the Python buildpack
added support for bin/report, its implementation was based on the
Node.js one, with some further small improvements.

However, there remains a number of issues with the design:
1. It handles different data types (string vs int vs float vs bool) at
   `bin/report` time, so requires a hardcoded mapping of values which
   can (and does) get out of sync. (Plus doesn't work well for some
   cases, like jvm-common being wrapped by the other JVM related
   buildpacks.)
2. It tries to escape newlines and carriage returns, but there are a
   number of edge cases still not handled properly which result in some
   fields not being sent to Honeycomb properly.

In order to work around the above, Manuel created a jq based approach
for use by the JVM buildpacks:
https://github.com/heroku/heroku-buildpack-jvm-common/blob/4fd6e4f8f258a5766a8b2e9ffec2690675b00879/lib/metrics.sh

However, that doesn't have the full API of the existing solution (it's
missing the ability to fetch previous values; something which Python
needs), and I spotted a few more places where things can be optimised.

In addition, now that we're using jq and JSON internally in the
buildpack, it makes sense for us to update cytokine to support the
build report being emitted as JSON too (in addition to YAML),
particularly since cytokine then submits the report to Vacuole as
JSON afterwards.

And in fact, since JSON is roughly a subset of YAML (at least for the
simple data types and schema we're using for the build report), we can
start emitting the build report as JSON now, rather than needing to wait
for the cytokine change to land first. (We'll still want to update
cytokine to use a JSON parser though, just to avoid any edge cases in
the future).

The new implementation:
- Sets the data type at the call site where the metadata is set,
  rather than relying on a hardcoded mapping at time of retrieval.
- Uses jq to do the string escaping, so much less fragile than the
  hand-rolled implementation.
- Uses a simplified initialisation/setup API, which avoids the need to
  call both `init` and `setup`.
- Has been rewritten to avoid unnecessary processes calls, redirections,
  and patterns that required disabling a number of shellcheck warnings.

I've confirmed that metrics still appear in Honeycomb with the changes
here.

After this merges, I'll open PRs against some of the other language
buildpacks that don't yet implement `bin/report`, using the improved
implementation from here (with simplifications since other buildpacks
won't need the legacy data store handling that Python needs to support
caches written by older buildpack versions).

GUS-W-19344754.

Signed-off-by: Ed Morley <501702+edmorley@users.noreply.github.com>

Co-authored-by: heroku-linguist[bot] <136119646+heroku-linguist[bot]@users.noreply.github.com>

* Bump uv from 0.8.9 to 0.8.13

Bumps [uv](https://github.com/astral-sh/uv) from 0.8.9 to 0.8.13.
- [Release notes](https://github.com/astral-sh/uv/releases)
- [Changelog](https://github.com/astral-sh/uv/blob/main/CHANGELOG.md)
- [Commits](astral-sh/uv@0.8.9...0.8.13)

---
updated-dependencies:
- dependency-name: uv
  dependency-version: 0.8.13
  dependency-type: direct:production
  update-type: version-update:semver-patch
...

Signed-off-by: dependabot[bot] <support@github.com>

* Add changelog entry

---------

Signed-off-by: dependabot[bot] <support@github.com>
Co-authored-by: dependabot[bot] <49699333+dependabot[bot]@users.noreply.github.com>
Co-authored-by: Ed Morley <501702+edmorley@users.noreply.github.com>

Built-in Bash (5.0+) variable, a float with microseconds precision.
Faster, simpler, and more portable (no longer requires GNU date).

Logging it with six digits worth of precision instead of the previous three, but a float is a float ;)

GUS-W-19404492.

Co-authored-by: Ed Morley <501702+edmorley@users.noreply.github.com>