[ZEPPELIN-6263] Refactor startZeppelin() into modular helper methods for clarity and maintainability

[ParkGyeongTae]

What is this PR for?

This PR refactors the startZeppelin() method in ZeppelinServer by extracting its core logic into well-named modular helper methods such as initJettyHandler(), initServiceLocator(), bindZeppelinServices(), etc. The purpose of this change is to improve readability, facilitate future maintenance, and allow better unit testing of individual steps in the startup process.

No functional behavior has been changed.

What type of PR is it?

Refactoring

Todos

• [x] - Extract helper methods from startZeppelin()

What is the Jira issue?

• Jira: https://issues.apache.org/jira/browse/ZEPPELIN-6263

How should this be tested?

N/A

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.

[Reamer]

What do you think about making the private methods static as well? With the current implementation, it is not clear to me in which order the private methods must be called.

[ParkGyeongTae]

@Reamer Thanks for the suggestion! Some private methods could indeed be made static if they don't rely on instance fields. However, many of them depend on instance state like zConf, jettyWebServer, or sharedServiceLocator, so making them static would complicate the design.

Regarding the call order clarity — I believe improving method naming or grouping related calls (e.g., in startZeppelin()) would be a better way to make the flow more understandable, rather than relying on static modifiers. Let me know what you think!