Unable to bootstrap Cartridge app if path is too long

I have created a simple cartridge app nested too deep in my file structure (see https://github.com/tarantool/cluster-federation/pull/207).

tt start

is successful, while

tt cartridge replicasets setup --bootstrap-vshard --name=cluster1

(after manually fixing https://github.com/tarantool/tt/issues/642) fails with the following error:

2024-09-11 18:14:49.330 [8718] main/129/remote_control/127.0.0.1:49356 evio.c:241 E> SocketError: unlink, called on fd 31, aka unix/:(socket), peer of unix/:/home/moiseevgeorgy/Development/github/tarantool/cluster-federation/example/tarantool2_to_tarantool3/instan: Address already in use
2024-09-11 18:14:49.330 [8718] main/129/remote_control/127.0.0.1:49356 F> can't initialize storage: unlink, called on fd 31, aka unix/:(socket), peer of unix/:/home/moiseevgeorgy/Development/github/tarantool/cluster-federation/example/tarantool2_to_tarantool3/instan: Address already in use

Btw, it seems that 4 out of 5 instances fail with this error and the remaining one fails after unsuccessful replication connect, so it is possible that some path is truncated from the tail and reused by tt/cartridge-cli/
cartridge module.

Trying to start the same app with cartridge-cli results in

Failed to start: Failed to build notify socket: Failed to bind socket: listen unixgram /home/moiseevgeorgy/Development/github/tarantool/cluster-federation/example/tarantool2_to_tarantool3/instances.enabled/cluster1/tmp/run/cluster1.s2-replica.notify: bind: invalid argument. Probably socket path exceeds UNIX_PATH_MAX limit

So it seems that basic pipeline doesn't work if path is too long. It is possible that the reason of the issue is either cartridge-cli or cartridge module itself. Still, even if that's the case and it cannot be fixed in tt, it would be nice to fast-fail and do not try to provide half-working workarounds for cartridge instances.

Reproduce the failure with tt start followed by tt cartridge replicasets setup --bootstrap-vshard --name=cluster1, using the long path described in the issue, and compare it with cartridge-cli startup. Read the handling around these CLI entry points and the socket-path errors, then ensure the workflow either supports the path or fails early with a clear explanation before partially starting instances.