add From<&str> For InfoKind

[cathay4t]

No description provided.

[codecov]

Codecov Report

❌ Patch coverage is 62.50000% with 6 lines in your changes missing coverage. Please review.
✅ Project coverage is 67.90%. Comparing base (1fb4bd7) to head (1558418).
⚠️ Report is 45 commits behind head on main.

Files with missing lines	Patch %	Lines
src/link/link_info/infos.rs	62.50%	6 Missing ⚠️

Additional details and impacted files

@@            Coverage Diff             @@
##             main     #262      +/-   ##
==========================================
- Coverage   68.10%   67.90%   -0.21%     
==========================================
  Files         144      146       +2     
  Lines       10103    10284     +181     
==========================================
+ Hits         6881     6983     +102     
- Misses       3222     3301      +79     

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

🚀 New features to boost your workflow:

• ❄️ Test Analytics: Detect flaky tests, report on failures, and find test suite problems.

[gemini-code-assist]

Code Review

This pull request refactors the InfoKind parsing logic by implementing From<&str> and updating the Parseable trait implementation to utilize it. A review comment identifies a performance regression where unknown link types now undergo a double allocation (String to &str and back to String). The reviewer suggests implementing From<String> for InfoKind to allow moving the string directly into the Other variant, avoiding the unnecessary clone.

[gemini-code-assist]

The refactoring to use From<&str> introduces a double allocation when parsing an unknown InfoKind (the Other variant).

parse_string returns a String. Calling s.as_str().into() then invokes InfoKind::from(&str), which calls s.to_owned() to create a second String for the Other variant, after which the original String is dropped.

While this only affects unknown link types, it is a performance regression compared to the previous implementation which moved the String into the Other variant. To resolve this while keeping the code clean, you could implement From<String> for InfoKind (which would move the string in the Other case) and use Ok(s.into()) here.