Allow modifying a Server's zbus connection builder

[DJ-Laser]

By default zbus Connections spawn a thread per connection, however this can be disabled by calling .internal_executor(false) on it's builder, and manually ticking it (in my case by spawning a future onto smol's executor).

While spawning another thread unnecessarily isn't a huge deal, being able to modify the connection builder in general could be very useful, even if gated behind the unstable feature.

Unfortunately Server::connection isn't much help, since the executor needs to be disabled before it's built, and can't be disabled after, and I don't see any good solutions to allow modifying the Server's connection that aren't breaking changes.

See:
https://docs.rs/zbus/latest/zbus/connection/struct.Connection.html#method.executor

[SeaDve]

I'm open to breaking changes. Do you have any recommendation of an API that would allow this without exposing other low level things?

[DJ-Laser]

Perhaps a builder-style api could work, eg ServerBuilder<T> Which would have with_track_list(&mut self) and with_playlists(&mut self) methods.
ServerBuilder::new(impl: T) would setup dbus for RootInterface and PlayerInterface as usual, and the with_track_list(&mut self) method, which intentionally has no arguments as it uses the T passed into ServerBuilder::new and is gated with T: TrackListInterface sets up the dbus for TrackList, and same for with_playlists(). In this manner there could also be a method that allows you to access the zbus connection builder, and only build the zbus connection when creating the server, eg. with a build(self) method.

Example of proposed usage:

// Sets up Root/Player dbus interfaces
let builder: ServerBuilder<Impl> = ServerBuilder::new(impl)
    // Sets up Playlists dbus interface
    // Impl must implement PlaylistsInterface
    .with_playlists()
    // Sets up TrackList dbus interface
    // Impl must implement TrackListInterface
    .with_track_list()
    // Access inner zbus conntion builder
    .access_inner_name_tbd(|builder, impl| {
        // Setup dbus connection
        return Ok(builder);
    });
    
let server: Server<Impl> = builder.build();

Server::new_inner already has a builder_ext_func parameter, so ServerBuilder::build could replace Server::new_inner with a struct field for either a list of builder_ext_funcs:

self.builder_ext_funcs.push(|builder, impl| {
    // Setup dbus connection
    return Ok(builder);
});

Or a single one that chain-calls previous functions:

self.builder_ext_func = |builder, impl| {
    // Setup dbus connection
    return prev_ext_func(builder, impl);
}

[DJ-Laser]

To reduce breaking changes, we could still keep the constructor methods on Server<T>, but change them to use ServerBuilder<T> internally, keeping it simpler for people who don't need the full builder api features.