Merge pki-types history into rustls repository

[djc]

This contains a merge commit, so I'm not sure we can/want to rebase it.

[codecov]

Codecov Report

Attention: 147 lines in your changes are missing coverage. Please review.

Comparison is base (a3bf6ba) 95.87% compared to head (edfdf5c) 95.57%.
Report is 2 commits behind head on main.

❗ Current head edfdf5c differs from pull request most recent head 0476586. Consider uploading reports for the commit 0476586 to get more accurate results

Files	Patch %	Lines
pki-types/src/lib.rs	0.00%	147 Missing ⚠️

Additional details and impacted files

@@            Coverage Diff             @@
##             main    #1462      +/-   ##
==========================================
- Coverage   95.87%   95.57%   -0.30%     
==========================================
  Files          77       72       -5     
  Lines       15779    15271     -508     
==========================================
- Hits        15128    14596     -532     
- Misses        651      675      +24     

☔ View full report in Codecov by Sentry.
📢 Have feedback on the report? Share it here.

[ctz]

I suggest when transferring the tags after this merges, we rename them (subdir)/(semver), eg, pki-types/0.2.1?

[djc]

Renaming them makes sense to me, I would paint this bikeshed the color hypen (pki-types-0.2.1).

[ctz]

And for the workflow yml, I suggest we name that by the subdirectory name too? If we keep a separate pki-types workflow, should we restrict it to running for changes that touch that subdirectory? I think I'd prefer to avoid having separate workflows for each sub-crate until and unless we find it too inflexible.

[djc]

And for the workflow yml, I suggest we name that by the subdirectory name too? If we keep a separate pki-types workflow, should we restrict it to running for changes that touch that subdirectory? I think I'd prefer to avoid having separate workflows for each sub-crate until and unless we find it too inflexible.

I think we can get away without separate workflows for now, especially since pki-types is very fast to build and we can relegate slower parts to the daily tests workflow.

[ctz]

I think we can get away without separate workflows for now, especially since pki-types is very fast to build and we can relegate slower parts to the daily tests workflow.

Agree. Do you want to have a commit in this PR that deletes .github/workflows/ci.yml and extends build.yml to format/clippy etc pki-types/?

[djc]

I think we can get away without separate workflows for now, especially since pki-types is very fast to build and we can relegate slower parts to the daily tests workflow.

Agree. Do you want to have a commit in this PR that deletes .github/workflows/ci.yml and extends build.yml to format/clippy etc pki-types/?

Yes, I think most of that will happen "automatically" because the PR makes pki-types part of the workspace, but I'll make sure to check.

[cpu]

I think this looks good, but admittedly I haven't reviewed many branches that perform a repo-wide git import.

[cpu]

@ctz @djc What needs to happen to move this forward? Is there a reason to defer the merge until a later date?

[ctz]

AFAICT the extra ci.yml has fallen away now.