[ZEPPELIN-6406] Integrate interpreter config key constants

[hyunw9]

What is this PR for?

Upstream issue ZEPPELIN-6400 removed the ZeppleinConfiguration dependency from the zeppelin-interpreter module and replaced it with a plain property-based approach.

As a subtask, fix these problems

Config key String (e.g. "zeppelin.interpreter.connection.poolsize") are hardcoded as plain string in RemoteInterpreterServer.java, TimeoutLifecycleManager.java, and SchedulerFactory.java. so typos can only be caught at runtime.
The same keys are defined independently in ZeppelinConfiguration.ConfVars, creating drift risk between two modules.
TimeoutLifecycleManager.parseTimeValue() duplicates the logic of ZeppelinConfiguration.timeUnitToMill().

What type of PR is it?

Refactoring

Todos

• - Add a few files in zeppelin-common to remove hardcoded properties
• - Replace String config variables with using added common property InterpreterConfigKeys in zeppelin-common module
• - Mark timeUnitToMill() @Deprecated and delegated to ConfigTimeUtils in zeppelin-common module

What is the Jira issue?

• [ZEPPELIN-6406]

How should this be tested?

• Simple property tests are added under zeppelin-common module(InterreterConfigKeysTest.java, ConfigTimeUtilsTest.java)

Questions:

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

---

[jongyoul]

I think it's a good starting point. Thank you.

[jongyoul]

@hyunw9 By the way, could you please handle npm-audit issue first with another PR if possible?

[Reamer]

Please remove the unnecessary test class. Everything else looks great.

[hyunw9]

@jongyoul @hyunw9 By the way, could you please handle npm-audit issue first with another PR if possible?

Sure, I’ll open a new issue and work on resolving it there.