fix($location): do not decode %2F codes in the path back to / characters

[petebacondarwin]

If the user has purposefully encoded forward slashes into their $location path
(i.e. the bit after the hashbang), then we should not forceably decode it,
since if you want forward slashes you are allowed to place them in an
unencoded form straight into a hash segment of a URL

Closes #13245

[petebacondarwin]

The main concern with this is that I had to change a previously passing test. But I think that this test was actually unnecessarily tight.

[Narretz]

LGTM

[gkalpak]

Since we are using encodeUriSegment on the hash, shouldn't we also use decodeUriSegment for the hash as well ?

[petebacondarwin]

Oh man! This location stuff is too convoluted. I am now not clear when we want to use our custom encoding/decoding and when not. I think it works at the moment, mostly be chance!

[christopherthielen]

The special slash handling in paths has been affecting ui-router also. See this recent analysis ticket: angular-ui/ui-router#2598

I think $location tries a little too hard to be helpful with the slashes and encoding, and we lose the capability to manage it ourselves.

It would be great if this were addressed, but I'd be concerned about introducing new behavior this late in the game. Perhaps an opt-in location service that allowed a bit more "raw" access would mitigate that possibility.

[abirmingham]

Any update on this? +1 @christopherthielen suggesting more configurability (or opt out of the $location service entirely).

[petebacondarwin]

The current state of affairs is this PR: #16354. See the link in the PR to follow the reasoning...