feat: optimize IdentifierError variants

[mina86]

Remove IdentifierError::Empty and ContainSeparator variants as they
are redundant. The former is a special case of InvalidLength; the
latter is a special case of InvalidCharacter.

With that, remove length checking from validate_identifier_chars
(which didn’t belong there anyway) and rely on check in
validate_identifier_length instead.

Closes: #978

---

PR author checklist:

• Added changelog entry, using unclog.
• Added tests.
• Linked to GitHub issue.
• Updated code comments and documentation (e.g., docs/).
• Tagged one reviewer who will be the one responsible for shepherding this PR.

Reviewer checklist:

• Reviewed Files changed in the GitHub PR explorer.
• Manually tested (in case integration/unit/mock tests are absent).

[codecov]

Codecov Report

All modified and coverable lines are covered by tests ✅

Comparison is base (45b1c97) 70.23% compared to head (251f9ef) 70.76%.
Report is 6 commits behind head on main.

Additional details and impacted files

@@            Coverage Diff             @@
##             main     #942      +/-   ##
==========================================
+ Coverage   70.23%   70.76%   +0.53%     
==========================================
  Files         177      178       +1     
  Lines       17733    17943     +210     
==========================================
+ Hits        12455    12698     +243     
+ Misses       5278     5245      -33     

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

[Farhad-Shabani]

Thanks @mina86. Just kindly note that you are touching parts that are getting refactored thru this PR as well: #941.

Let me page @rnbguy to look into these points and apply the relevant changes there (particular first one).

[Farhad-Shabani]

@mina86, also on a side request:
Really appreciate if you open an issue and put the description there before making any changes and link that to your PR.
This way, it won't disrupt our project board and helps us prioritize things. We're trying to be efficient with our bandwidth. So, if something's lower on the priority list, we can give you the heads up, so you won't waste time on it.
Thanks!

[rnbguy]

hey @mina86, #941 and this PR are in conflict. Please wait till we merge #941.

[rnbguy]

The PR has been merged, you may continue with your PR 🙂 but it is now in conflict with main branch.

[mina86]

@mina86, also on a side request: Really appreciate if you open an issue and put the description there before making any changes and link that to your PR. This way, it won't disrupt our project board and helps us prioritize things. We're trying to be efficient with our bandwidth. So, if something's lower on the priority list, we can give you the heads up, so you won't waste time on it. Thanks!

From my point of view I’d rather write a PR and then be told that the review is low on priority list than create an issue. I often don’t exactly know what I want and by the time I formulate an Issue I already have code written for it. If that’s the only concern than I’d prefer not deal with Issues. ;) But let me know if me sending PRs break your workflow.

I guess two features that I’m pretty sure I’d love to have for sure are efficient zero-copy TryFrom<Vec<u8>> and TryFrom<String>> implementations for the identifiers.

[rnbguy]

Thanks 👍

[rnbguy]

Thanks for the optimization ! 🎉