ssa.c: Cosmetic change to reconnect log message in ssa_upstream_handler

Signed-off-by: Hal Rosenstock <hal@mellanox.com>
Eliminate race between core initialization and SSA MAD receipt

It is possible for SSA MAD to be received by core prior to
core->list_lock mutex being initialized by core_init_svc (and
this has been occasionally observed). Receipt of SSA MAD
causes core->list_lock mutex to be taken but if it's not already
initialized, the lock never completes.

For ACM connecting to combined core node, the core layer SSA
log (ibssa.log) contains:
Dec 17 22:24:37 482714 [CTRL]: ssa_ctrl_run: port event on fd 11
Dec 17 22:24:37 482763 [CTRL]: ssa_ctrl_port: mlx4_0:1 receiving MAD
Dec 17 22:24:37 482795 [UP mlx4_0:1:1]: core_process_msg: mlx4_0:1:1
Dec 17 22:24:39 482259 [CTRL]: ssa_ctrl_run: port event on fd 11
Dec 17 22:24:39 482289 [CTRL]: ssa_ctrl_port: mlx4_0:1 receiving MAD
Dec 17 22:24:43 482248 [CTRL]: ssa_ctrl_run: port event on fd 11
Dec 17 22:24:43 482282 [CTRL]: ssa_ctrl_port: mlx4_0:1 receiving MAD
Dec 17 22:24:51 482225 [CTRL]: ssa_ctrl_run: port event on fd 11
Dec 17 22:24:51 482262 [CTRL]: ssa_ctrl_port: mlx4_0:1 receiving MAD
Dec 17 22:25:07 482239 [CTRL]: ssa_ctrl_run: port event on fd 11
Dec 17 22:25:07 482273 [CTRL]: ssa_ctrl_port: mlx4_0:1 receiving MAD

In order to fix this, move the application specific initialization
into ssa_start_svc after the ssa_svc structure allocation occurs.
If the application specific initialization does not succeed,
then application specific destruction is needed as well.

So ssa_start_svc now contains 2 additional routines: init_svc
and destroy_svc which are application specific. distrib and acm
have default routines whereas core uses the already implemented
core_init_svc and core_destroy_svc routines.

Signed-off-by: Hal Rosenstock <hal@mellanox.com>