Need to fix fragmented patterns on Integration Test starter APIs

[plebhash]

Role starter APIs on Integration Test framework is starting to slip into some fragmented patterns, which is resulting in a suboptimal user experience while writing tests.

I noticed this while doing the experimentation described here: #1226 (comment)

Given that #1226 hasn't yet been merged, I believe it can be used to address start_jdc and start_jds.

But start_sniffer, start_pool and start_template_provider probably deserve a separate PR (ideally in sync with #1226).

Here's a detailed description of each fragmented pattern:

arg types

All starter functions take parameters with Socket Address information.
However, each role is following a different standard:

• start_sniffer takes SocketAddr
• start_pool takes Option<SocketAddr>
• start_template_provider takes u16 (representing a port)
• start_jdc takes SocketAddr (not yet merged, WIP under Add JDC/S initializers in integration tests #1226)
• start_jds takes SocketAddr (not yet merged, WIP under Add JDC/S initializers in integration tests #1226)

assumptions on roles socket addresses

Not all starter functions are taking Socket Address information for the actual role.

• start_sniffer assumes sniffer_addr will be provided by the user
• start_pool assumes pool_addr will be provided by the user
• start_template_provider assumes tp_addr will be provided by the user
• start_jdc assumes nothing is provided, but calls common::get_available_address() inside the function body (not yet merged, WIP under Add JDC/S initializers in integration tests #1226)
• start_jds assumes nothing is provided, but calls common::get_available_address() inside the function body (not yet merged, WIP under Add JDC/S initializers in integration tests #1226)

To be honest, I feel it makes more sense to always call common::get_available_address() inside the function bodies and simply abstract that away from the user (potentially even making common::get_available_address() into a private function under common).

In other words, I think the direction start_jdc and start_jds are taking is better than the other starters.

return types

Starter functions are returning types under different patterns:

• start_sniffer returns Sniffer
• start_pool returns PoolSv2
• start_template_provider returns TemplateProvider
• start_jdc returns SocketAddr (not yet merged, WIP under Add JDC/S initializers in integration tests #1226)
• start_jds returns SocketAddr (not yet merged, WIP under Add JDC/S initializers in integration tests #1226)

[jbesraa]

Totally agree with the stance here. I was about to address this after completing #1226 as it made it more clear how we should approach this.