Remove public-api lockfiles

[AdamGS]

Summary

This PR removes the public-api lockfile mechanism, we don't actually use it to inform decisions, changes or the changelog. Its often just a chore that needs to be handled in CI/locally.

We should hold ourselves to a higher standard in PRs descriptions and when working on public APIs (especially widely used ones), that seems more important than every minor change in the API semantics because of some trait bound change.

[codspeed-hq]

Merging this PR will not alter performance

⚠️ Unknown Walltime execution environment detected

Using the Walltime instrument on standard Hosted Runners will lead to inconsistent data.

For the most accurate results, we recommend using CodSpeed Macro Runners: bare-metal machines fine-tuned for performance measurement consistency.

✅ 1251 untouched benchmarks

---

_{Comparing adamg/remove-public-api-lock (163670f) with develop (c84205b)¹}

Footnotes

1. No successful run was found on develop (25c0ff3) during the generation of this report, so c84205b was used instead as the comparison base. There might be some changes unrelated to this pull request in this report. ↩

[joseph-isaacs]

[joseph-isaacs]

I think we should either have a plan on what we should do with these or remove them!

[robert3005]

I think we should introduce them per crate and not on the whole repo. We can remove them now and go bottom up making it harder to merge things that change public apis. Though practically I think it would just be committing to marking things a break if public apis are touched and maybe additional review for adding new public apis

[AdamGS]

A lot of our core APIs are still in flux, we can make it a higher priority as part of reviews and general thinking, but until we reach a point of actual stability, I don't see the value of automated tooling here.

[0ax1]

I think the lock-files had the right intention trying to keep the API stable but a) lock diffs are too large and b) we always ignore them. I haven't seen a PR not merge bc of an API change being highlighted by a lock-file. So rn this is really just noise and churn. So the lock-files don't seem like the right tool / abstraction level to reason about breaking API changes.