Intended behaviour for zip file names

[piksel]

Since #362 we changed the behaviour of the file name mapping for zip archives. The current state means that we have 3 failing tests, which is due to them relying on the library to automatically strip the root from the paths.
Since this is probably what most consumers actually want, that transform should be added again, but only for creating/writing archives.
Then there is the question of handling the explicitly set "unsupported" file names (like proposition?.pdf). We should probably throw an exception in those cases, but allow a bool to be passed that governs whether it should be cleaned or allowed. Doing either by default would probably just cause confusion.

Prior discussions and background can be found in #341

Any thoughts or clarifications @Numpsy ?

[Numpsy]

Putting the separators/slashes into the correct format seems right, as does (maybe in a configurable fashion) stripping the path roots (not doing so maybe has ramifications for 'zipslip' and such as well as being unexpected?)

I don't know if the code should internally care about characters that might be invalid on certain file systems (as opposed to things that the zip spec doesn't allow) though?
I recall from testing one of these issues in the past (might have been #341) that the described error didn't occur on .NET Core because MS have removed the character validation from functions like IsPathRooted and left it just down to the functions that actually interact with the file system, as it's too 'flakey' otherwise?

Giving ZipOutputStream a NameTransform to use and making that configurable might help fix the issues and make it consistent with other things, though I have a slight recollection of trying that once and having an issue with FastZip due to names being transformed twice (I can't recall the details though :-( )

[Numpsy]

Is this area sufficiently resolved now?

[piksel]

I think it is.