enhance: handle ../ in aria-current for A tags

[TERRORW0LF]

This correctly sets the aria-current attribute on a tags when the provided href matches the current location after resolving the href for page back navigations (../).

Rust playground suggests this to be around a 1.5 ms performance hit for a vector of 100000 elements, but that probably doesn't mirror real world examples. This could be made faster by replacing the insert_str with push_str and reversing the iterator before the fold again, but that break the filter.

[gbj]

I'm not at all concerned about the performance.

The logic looks right to me, and some simple tests suggest it works. Would you mind refactoring the added lines into a separate function and adding a few tests for it?

[TERRORW0LF]

The refactoring is no problem. I haven't written any tests for the web before though, is there any example in the repo which I could use as orientation? I tried looking around but couldn't really find much.

[gbj]

This does not require any web tests as far as I can tell, it is just a matter of refactoring into a Rust function that takes and returns string types and writing normal #[test] tests for that.

[TERRORW0LF]

Oh yeah, that makes things a lot easier. I don't know what I thought I had to test for the aria-current component.

Anyway, I'm currently writing the tests and have noticed that browsers implement the resolution of links ending in .. differently from each other. Firefox resolves /home/faq/.. to /home/ while chromium (I tested with brave so it might be a brave specific thing) resolves it to /home. This will make is_active_for with strict_trailing_slash = true match the route on some browser and not on others, no matter how we decide to handle this case.

[TERRORW0LF]

Reading the RFC Firefox apparently has the correct parsing, while Chrome is technically non-compliant. I'll update the PR to do the compliant version for now.

It also allows you to backtrack further than the root, just ignoring those backtracks, which I also now implemented.

The only thing I didn't include is handling of ../ and ./ as the first path segment since the input should be guaranteed to start with a slash in our case.