`tt replicaset` fails to recognize the `custom` orchestrator type for applications without configuration

Problem Description

When working with applications that lack a configuration, the tt replicaset command is unable to determine the custom orchestrator type. For instance, the following issue occurs when attempting to use tt replicaset with such an application:

1. Starting a single application:

/start-from-snap $ tree
.
├── init.lua
├── ready
├── tt.yaml
└── var
    ├── lib
    │   └── start-from-snap
    │       └── 00000000000000000000.snap
    ├── log
    │   └── start-from-snap
    │       └── tt.log
    └── run
        └── start-from-snap
            ├── tarantool.control
            ├── tarantool.sock
            └── tt.pid

2. Checking the application status:

/start-from-snap $ tt status
 INSTANCE         STATUS   PID   MODE  CONFIG         BOX      UPSTREAM
 start-from-snap  RUNNING  3127  RW    uninitialized  running  --

3. Attempting to check the application replicates status:

/start-from-snap $ tt replicaset status start-from-snap
   ⨯ config:get(): no instance config available yet

But if you configure the orchestrator manually, then everything is ok.

/start-from-snap $ tt replicaset status start-from-snap --custom
Orchestrator:      custom
Replicasets state: bootstrapped

• 8a89be87-43af-4f0f-82f2-23e56959b2a3
  Failover: unknown
  Master:   single
    • start-from-snap unix/:/.../start-from-snap/tarantool.sock rw

Discussion

The error config:get(): no instance config available yet indicates that the tt replicaset command does not handle applications without a defined configuration. According to the discussion, this appears to be a missing implementation for the custom orchestrator type, which should be used in such cases.

Discussion: https://github.com/tarantool/tt/pull/936#discussion_r1817006860

Start at the tt replicaset command entry point and reproduce the reported tt replicaset status start-from-snap case using an application without configuration. Compare it with the explicit --custom invocation and the discussion linked in the issue. Done means the command recognizes the custom orchestrator automatically and reports replicaset status without the configuration error.