s3n:// incorrectly handles URLs with secret keys that contain a slash

This is similar to HADOOP-3733, but happens on s3n:// instead of s3://.

Essentially if I have a path like "s3n://key:pass%2Fword@example.com/test", it will under certain circumstances be replaced with "s3n://key:pass/test" which then causes "Invalid hostname in URI" exceptions.

I have a unit test and a fix for this. I'll make a pull request in a moment.