[WIP] Add transport channel and server factory abstractions

[mohit7705]

Which issue does this PR close?

Related to #1367

Rationale for this change

Currently, client, scheduler, and executor components create transport connections
directly, which makes it difficult to extend or customize transport behavior
(e.g. adding optional TLS support).

This PR introduces transport-level factory abstractions as a first step toward
supporting optional TLS while keeping plain HTTP as the default.

What changes are included in this PR?

• Introduces a new ballista::core::transport module
• Adds ChannelFactory and ServerFactory traits
• Provides default factory stubs preserving existing behavior
• Adds TLS factory stubs to demonstrate future extensibility

Are there any user-facing changes?

No. This PR does not change any runtime behavior and does not introduce TLS yet.

Are there any breaking changes?

No.

[mohit7705]

@milenkovicm I’ve opened a draft PR with the initial transport channel and server factory abstractions discussed in #1367.

This PR only introduces the structure (no behavior changes, no TLS yet) to validate the direction before wiring it into scheduler/client code.

Happy to iterate based on feedback.

[milenkovicm]

Hey @mohit7705
This PR does not do anything, am I missing something? perhaps you forgot to commit other files?

Also, for transparency purposes do you use any code generation LLMs for this pr?

[mohit7705]

Thanks for checking and for the questions.

You’re right — this PR is intentionally limited to introducing the factory abstractions
and does not wire them into existing scheduler/client code yet. The goal was to first
validate the structure and placement before touching behavior-critical paths.

If this direction looks reasonable, the next step would be to:

• Wire the default factories into the existing channel/server creation points
• Replace direct instantiation with the factory usage (without changing behavior)

Regarding code generation: yes, I did use an LLM as an assistant for drafting and refining
the initial trait and struct scaffolding, but all code was reviewed, adapted, and
manually integrated by me.

Happy to update the PR to include the initial wiring if that’s preferred.

[milenkovicm]

All right, thanks for clarification.

Please take initiative and implement your idea, once you are happy with state of implementation we can do review

Until then I'll mark this pr as a draft

[milenkovicm]

hey @mohit7705 any progress on this? do you need any help ?

[mohit7705]

Hey @milenkovicm , thanks for checking in!
I’m making progress on wiring the default factories into the existing code paths. I have exams ongoing this week, so progress is a bit slower than usual, but I’m continuing to work on this and plan to push an update to the PR shortly after the current exam window.
I’ll reach out if I get stuck — thanks for offering help!

[milenkovicm]

closing in favour of #1400