fix: stop using deprecated HttpCommandExecutor and BiDi APIs from Selenium 4.50

[diemol]

Change list

• Bump Selenium to 4.50.0.
• AppiumCommandExecutor keeps its own HttpClient.Factory and uses the new HttpCommandExecutor(HttpClient, Map, URL) constructor.
• AppiumCommandExecutor.getClient() is now public, so AppiumDriver no longer reads HttpCommandExecutor.client.
• The server URL now comes from AppiumClientConfig or AppiumDriver.getRemoteAddress(), not from getAddressOfRemoteServer().
• AppiumDriver overrides getHandle(), which is the new way Selenium gives BiDi access.
• No more reflection on HttpCommandExecutor.client:
  • Direct connect switches the target of a small wrapper client (SwitchableHttpClient) instead of replacing the field. The old client is now closed.
  • If someone passes their own HttpCommandExecutor, AppiumDriver creates its own HTTP client for the log websockets (same as BiDi already does) and closes it on quit().

Types of changes

What types of changes are you proposing/introducing to Java client?
Put an x in the boxes that apply

• No changes in production code.
• Bugfix (non-breaking change which fixes an issue)
• New feature (non-breaking change which adds functionality)
• Breaking change (fix or feature that would cause existing functionality to not work as expected)

Details

Selenium 4.50 deprecated some HttpCommandExecutor fields and methods that Appium uses (SeleniumHQ/selenium#18038, SeleniumHQ/selenium#18098). In Selenium 4.52, client becomes protected and httpClientFactory is removed. Without this change, Appium would break with Selenium 4.52.

Notes:

• The minimum Selenium version is now 4.50.0, because the new constructor only exists from that version.
• getBiDi() and maybeGetBiDi() stay. Selenium deprecated them, but it has no replacement yet for listeners on one browsing context, such as NATIVE_CONTEXT.
• getAddressOfRemoteServer() is still called only when someone passes their own HttpCommandExecutor (not Appium's). Selenium has no replacement for that case.
• After this change, the build has no deprecation warnings from Selenium.

🤖 Generated with Claude Code

[diemol]

I am leaving this parked for a while since the current code does not look good. I made a couple of changes in Selenium to improve this PR but I need to wait for 4.51 to be released. If it is ok with you, please leave this PR open and I will come back to it after the next Selenium release.

[mykola-mokhnach]

Thanks @diemol

After applying several breaking changes to reduce the amount of shared code java client does not have any more dependencies to any of selenium libs, but selenium-api only (and partially remote-driver) that limits the shared portion to common interfaces without relying on concrete implementations.

I believe my recent changes would allow to improve the synergy between teams and focus primarily on the contract rather than implementation details.

Preliminary migration guide for the upcoming major release: https://github.com/appium/java-client/blob/master/docs/v10-to-v11-migration-guide.md

[diemol]

@mykola-mokhnach does your comment mean that this PR won't be needed in the future?

[mykola-mokhnach]

@mykola-mokhnach does your comment mean that this PR won't be needed in the future?

Yes. As of #2462 and #2463, the Java client no longer depends on HttpCommandExecutor or the Selenium HTTP client. It uses selenium-api plus the bridge module, so this PR can be closed.