refactor: replace enum sandboxType to string sandboxType

[ShenJunkun]

Description

This PR addresses #65 by replacing the rigid SandboxType enum with a string-based identifier. This change allows users to register custom sandbox types beyond the built-in options, supporting diverse scenarios like domain-specific images or custom security policies.

Changes

• Replaced SandboxType enum with String in @RegisterSandbox and registry logic.
• Defined SandboxType constants to maintain backward compatibility.
• Updated the identification key to (userId, sessionId, sandboxType).

Checklist

• My code follows the code style of this project.
• I have performed a self-review of my own code.
• All new and existing tests passed.

[cla-assistant]

All committers have signed the CLA.

[cla-assistant]

Thank you for your submission! We really appreciate it. Like many open source projects, we ask that you sign our Contributor License Agreement before we can accept your contribution.
_{You have signed the CLA already but the status is still pending? Let us recheck it.}

[xuehuitian45]

Hello,I noticed in your PR that SandboxType has been changed to a String type, which is great. However, I encountered the following issue during usage:

When I followed the instructions in the previous cookbook to implement a custom sandbox, I set SandboxType to SandboxType.Custom and assigned my desired name to CustomType. However, the sandbox was not created using my specified imageId—it fell back to the default behavior. In contrast, using the original approach (without CustomType) works correctly.

I found the root cause lies in the following area:

Image lookup logic:
During sandbox creation in SandboxManager.java, the system calls SandboxRegistryService.getImageByType() to retrieve the image name. However, this method only retrieves CustomType in typeConfigRegistry, which cannot be found. Actually, the custom types are only registered in customTypeRegistry.

To solve this problem, I modified the getConfigByType method in SandboxRegistry as follows:

return Optional.ofNullable(typeConfigRegistry.get(sandboxType))
.or(() -> Optional.ofNullable(customTypeRegistry.get(sandboxType)));

This partially resolves the issue when there is only one custom sandbox per session, but the fundamental problem remains: the system still uses SandboxType (i.e., "Custom") instead of the actual custom type name (CustomType) for sandbox identification and management. While workarounds are possible, this design is not elegant and will likely confuse users.

Also, I found that there could also be a problem harder to encounter:

Sandbox identity/key management:
The SandboxManager uses a composite key - SandboxKey consisting of userId, sessionId, sandboxType, and (only in AgentBay cases) imageId to manage created sandboxes. Since all custom sandboxes now share the same sandboxType (SandboxType.Custom), multiple distinct custom sandboxes within the same session cannot be properly distinguished, leading to incorrect ContainerModel retrieval.

My Recommendation

I suggest completely deprecating the SandboxType enum concept and instead using a plain String as the universal, first-class identifier for all sandbox types—both built-in and custom.

Specifically:

• Eliminate the distinction between "predefined types" and "custom types".
• Treat every sandbox type (e.g., "browser", "filesystem", "my-custom") as an equal string identifier.
• Remove the CustomType field entirely; the sandbox type is the string name.

This simplifies the architecture, avoids key collisions, and provides a consistent user experience.

Note: Given your recent changes, please also update the relevant documentation in the Cookbook folder accordingly and add stricter tests.