Co-authored-by: NSteve Yurong Su <rong@apache.org>

[IOTDB-6081] Pipe: use HybridExtractor instead of LogExtractor when realtime mode is set to log to avoid OOM under heavy insertion load (#10620)

* When user specifies 'extractor.realtime.mode'='log', we use hybrid extractors which can automatically degrade to file mode when load is too heavy.

* Add a parameter: 'extractor.realtime.mode'='forced-log', the pipe will always use log mode and will never degrade to file mode.

---------
Co-authored-by: NSteve Yurong Su <rong@apache.org>

## Description
After loading tsfile, it causes 100% load on one CPU core.

## Reason
Root cause: high processor load for ScheduledThreadPoolExecutor with 0 core threads. It was a bug in JDK1.8.

See the following issues for more details:
[JDK-8129861](https://bugs.openjdk.java.net/browse/JDK-8129861)
[JDK-8022642](https://bugs.openjdk.java.net/browse/JDK-8022642)

## Solution
1. Set corePoolSize to 1 to avoid high processor load (a workaround)
2. Lazy initialization: init loadTsFileManager on first call (to avoid unnecessary threads' creation)

[IOTDB-6075] Pipe: File resource races when different tsfile load operations concurrently modify the same tsfile at receiver (#10629)

* Add a parameter in iotdb-core/node-commons/src/assembly/resources/conf/iotdb-common.properties to control the connection timeout.
* Set the pipe connection timeout between sender and receiver to 15 mins to allow long time-cost load operation.
* Redesign the pipe receiver's dir to avoid file resource races when different tsfile load operations concurrently modify the same tsfile.

Make the candidate size of seq tsfile in cross space compaction will be smaller than target_compaction_file_size * 1.5. (#10602)