Add runtime size configuration feature

[neubig]

This PR adds a new feature to configure the runtime size in the settings modal. Users can now choose between 1x (2 core, 8G) and 2x (4 core, 16G) options.

Changes include:

• Added a new REMOTE_RUNTIME_RESOURCE_FACTOR field to the Settings type
• Created a new RuntimeSizeSelector component
• Updated the SettingsForm component to include the new selector
• Modified getSettings and saveSettings functions to handle the new setting
• Updated tests to include the new setting
• Added documentation about the new runtime size option in the README.md file

Please review and let me know if any changes are needed.

---

Notes:

1. Fixes [Feature Request]: Set RemoteRuntime size in frontend #5797
2. This is pending review by @neubig

---

To run this PR locally, use the following command:

docker run -it --rm   -p 3000:3000   -v /var/run/docker.sock:/var/run/docker.sock   --add-host host.docker.internal:host-gateway   -e SANDBOX_RUNTIME_CONTAINER_IMAGE=docker.all-hands.dev/all-hands-ai/runtime:626a4fb-nikolaik   --name openhands-app-626a4fb   docker.all-hands.dev/all-hands-ai/openhands:626a4fb

[neubig]

This looks good to me now, @amanape it'd be great if you could do a second review.

[amanape]

Is the backend already set to recognize these new setting keys?

[neubig]

@amanape : yes it is

OpenHands/openhands/core/config/sandbox_config.py

Line 61 in a2e9e20

remote_runtime_resource_factor: int = 1

UPDATE: but now that I think about it, I didn't carefully check the backend code that receives the changes from the frontend, I will check that.

[neubig]

OK, I think this is ready now @amanape ! This is what it looks like for now, and we'll enable the menu in a future PR once we have a way to pipe in info about which users should have access to this feature.

[neubig]

Actually, sorry, let me take another look at this. Please cancel that.

[neubig]

OK @amanape , I believe this is ready for review, thanks for the patience!

[amanape]

I've simplified FE tests and removed the services/settings test since it doesn't actually test relevant logic properly and also includes always passing tests e.g.,

vi.mocked(OpenHands.saveSettings).mockResolvedValueOnce(false);
const result = await OpenHands.saveSettings(apiSettings);

expect(result).toBe(false);

Makes it more confusing too

The rest LGTM!