Implement labels

[str4d]

Closes #403.

[codecov]

Codecov Report

Attention: Patch coverage is 29.53020% with 105 lines in your changes missing coverage. Please review.

Project coverage is 50.71%. Comparing base (d2c2e89) to head (3c9483f).
Report is 6 commits behind head on main.

Files	Patch %	Lines
age-plugin/src/recipient.rs	0.00%	43 Missing ⚠️
age/src/error.rs	0.00%	25 Missing ⚠️
age/src/plugin.rs	0.00%	24 Missing ⚠️
age-core/src/plugin.rs	46.66%	8 Missing ⚠️
age-plugin/src/identity.rs	0.00%	2 Missing ⚠️
age/src/protocol.rs	83.33%	2 Missing ⚠️
age-core/src/format.rs	83.33%	1 Missing ⚠️

Additional details and impacted files

@@            Coverage Diff             @@
##             main     #514      +/-   ##
==========================================
- Coverage   51.31%   50.71%   -0.61%     
==========================================
  Files          42       42              
  Lines        3946     4058     +112     
==========================================
+ Hits         2025     2058      +33     
- Misses       1921     2000      +79     

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

[FiloSottile]

Hmm, this is an interesting decision, should a postquantum plugin refuse to work with older versions of age(1)?

[str4d]

That was my interpretation, given this language in C2SP/C2SP#37:

• Clients MUST check that all recipient stanzas wrapping a given file key have the exact same label set. Clients MUST NOT permit partial overlapping sets.
• If the plugin does not respond with a labels command in phase 2, clients MUST treat the plugin's recipient stanzas has having an empty label set.

That means if the client does not advertise support for the labels extension, the plugin knows that if it proceeds apace, it will be forced to use the empty label set, which would be in violation of its desired non-empty label set. Maybe some plugins would accept that kind of fallback? But because plugins only see their relevant recipients, they cannot know what other recipients they will be combined with (the precise reason we designed the labels extension).

If we think this should be a per-plugin decision, I could add an associated constant to the trait (or alter the new labels method to return a boolean) that forces the plugin to declare whether it would allow its labels to be ignored by older clients. But that feels a bit weird.

[str4d]

I want to add plugins to the interoperability testing in order to test these changes between age and rage, but as that will likely require some trial-and-error, I'm going to do so in a separate PR.