Rework relay

[Gerold103]

The relay right now is a quite sad state.

• It consists of multiple crutches. The most prominent is about the subscribe thread having just a single fiber for processing 2 cbus endpoints AND writing to the socket. It has already led to a pile of crutches on top of each other: 30ad4a5, 1728944, ee6de02, and another one is incoming in A replica may timeout while master is scanning xlogs #9094.
• It has this weird opaque API - struct relay is hidden in .cc file and even the simplest access to it has to go via a function).
• Some of struct relay members are not needed. For example, wal_endpoint, tx_endpoint, and wal_watcher could easily exist just inside relay_subscribe_f - they are used only by it, could be there on the stack.
• It is suboptimal. Each row/txn is sent into the socket individually. This has led to another future crutch in https://github.com/tarantool/tarantool-ee/issues/706 (relay buffering).
• It is a confusing mix of C and C++ leading to already existing hidden bugs and future ones too. For instance, relay_subscribe_f calls struct fiber *reader = fiber_new_xc(name, relay_reader_f);, but if it throws an exception, then many things will not be cleaned up from above this line and will most likely just crash.
• struct relay TX members must be moved into struct replica. Relay can't access them anyway from its threads. There must be clear separation of objects. One struct living in 2 threads at once makes it hard to protect from races.

Relay at this point seems beyond microfix-saving and has to be reworked quite significantly. A good start would be to consider the architecture of one fiber per one job, so one fiber for TX messages processing, one fiber for socket reading, one fiber for socket writing, one fiber for WAL event processing. No crutches with WAL yield callback doing heartbeats and TX processing at once, and hacks to avoid accidental sending of a heartbeat during sending a TX. This won't be needed if the writer-fiber would take whole packs of data to send, and send them linearly.

As a buffer the senders (heartbeats and Raft messages from TX-processor-fiber, and txns from WAL-processor-fiber) could have their own lsregions and would be notified when their next data pack was sent, to propagate their lsregions. Callback-wise it would be similar to how boost::asio::async_send works.