Feat: Add fast boot

[SmartManoj]

What is the problem that this fixes or functionality that this introduces? Does it fix any open issues?

It is separated from #2455. Currently, it takes ~20 seconds to initialize plugins.

Give a brief summary of what the PR does, explaining any non-trivial design decisions

Why is initialize_plugins=0 not enough?

• When the container is stopped, the jupyter server is stopped too. So, I introduced a new sandbox config fast_boot to not stop containers for persistent sandboxes.

Is fast_boot == not initialize plugins?

• No. For the first time, if one sets initialize_plugins, then "not initialize_plugins" will fail and the sandbox will be stopped. The effect is that the jupyter server will also be stopped. Then one needs to set initialize_plugins again and it will lead to an endless loop.

[yufansong]

I prefer to close this PR. I don't think this feature is necessary. Using those configs to do trival control on our logic is bad. Will add too much tech debt on codebase.

[SmartManoj]

Currently, it takes ~20 seconds to initialize plugins.

Then how to solve this?

[yufansong]

Currently, it takes ~20 seconds to initialize plugins.

Then how to solve this?

We are working on refactor the runtime-sandbox-docker architecture now. When it get finished, part of the work of initialization will did in docker when build image. Then it will be much quicker. And we also will deprecated the ssh box logic.

[yufansong]

After discussion, close it now.

[SmartManoj]

refactor the runtime-sandbox-docker architecture now.

Is there any issue tracking this?

#2059 (comment)

#2360 (comment)

[yufansong]

#2404 track our refactor work.