[ZEPPELIN-6692] centralize folder path handling

[gyowoo1113]

What is this PR for?

Folder paths are currently handled differently depending on the operation. Some call sites add a leading /, while others pass the path unchanged. Some lower layers also assume a particular path form without checking it.

This can cause the same folder path to be interpreted differently depending on how it reaches the repository. For example, VFSNotebookRepo uses substring(1) assuming that the path starts with /, so a relative path can silently lose its first character.

This PR centralizes folder path normalization in NotebookService. Rename, move-to-trash, restore, and remove now use the same normalization so paths with or without a leading / are passed to lower layers in the same absolute form. The operation-specific leading-slash handling in NotebookServer is removed accordingly.

NotebookService is used as the normalization point because all four affected folder operations pass through it before reaching NoteManager. This also keeps the shared normalization out of the individual NotebookServer handlers and lets the service apply the same rule to all four operations.

VFSNotebookRepo also checks for the leading slash before using substring(1), so an unexpected relative path is rejected instead of being silently truncated. The validation is currently applied to VFS, where the leading-slash assumption directly affects this path handling. It can be extended to other NotebookRepo implementations if needed as part of this PR.

What type of PR is it?

Bug Fix

Todos

• Centralize folder path normalization in NotebookService
• Remove operation-specific folder path compensation from NotebookServer
• Apply the shared folder path convention to rename, trash, restore, and remove
• Reject non-absolute folder paths in VFSNotebookRepo
• Add regression tests for folder path normalization and VFS validation

What is the Jira issue?

[ZEPPELIN-6692]

How should this be tested?

./mvnw test -pl zeppelin-server -Dtest='NotebookServiceTest,NotebookServerTest,VFSNotebookRepoTest'

Screenshots (if appropriate)

N/A

Questions:

• Does the license files need to update? No
• Is there breaking changes for older versions? No
• Does this needs documentation? No

[tbonelee]

Normalizing at the service boundary and rejecting in the repository looks fine, since it matches how normalizeNothePath already works.

That said, some of validation normalizeNotePath used to do seems needed for folder paths as well, and looks like it was dropped in this PR. Rejecting .. segments and normalizing URL encoding in particular.

Would it make sense to gather the rules both need in one place so the two methods can share them? NotebookPathValidator seems like a reasonable spot, though it probably needs some thought on where to draw the line.

[gyowoo1113]

Thanks, that makes sense. I intentionally kept the folder normalization limited because I wasn’t sure which note-path rules should also apply to folder paths. I agree that URL encoding normalization and traversal-segment validation are relevant to folder paths as well. I’ll take a closer look at which common rules belong in NotebookPathValidator while keeping note- and folder-specific behavior separate.