[leo_object_storage][test] Cover issues found during 1.3.1 development

[mocchira]

As lots of issues about compaction found during 1.3.1 development cycle,
I'd like to add tests to cover those.

• [data-compaction][leo_object_storage] consume the cpu more than necessary during skipping a garbage block #520 (add huge garbage blocks and check properly skipping within reasonable time)
• [data-compaction][leo_object_storage] elements in pid_pairs may leak when the exec time of a compaction|diagnose is too short #521 (add check pid_pairs in leo_compact_fsm_controller is empty after every test finished)
• [leo_object_storage] leo_compact_worker_x get stuck during skipping a garbage block #522 (add calls sys:get_state/1 to leo_compact_fsm_workers running compaction|diagnose)
• [data-compaction][leo_object_storage] compaction|diagnose may get slow down when a garbage exist at the end of a avs #523 (already covered by existing cases)
• [data-compaction][leo_object_storage] leo_compact_fsm_controller cause the compaction status inconsistent when executing compaction|diagnose in parallel #524 (will be coverd by the check for [data-compaction][leo_object_storage] elements in pid_pairs may leak when the exec time of a compaction|diagnose is too short #521)
• [data-compaction][leo_object_storage] leo_fsm_compact_worker's Module:terminate don't free the resources up properly #526 (update the same record many times to cause leveldb start compaction and kick compact|diagnose afterwards)
• [leo_object_storage] More strictly checking the header, less file:pread(s) for reading a body #527 (add invalid records which break one of the new rules and check properly skipping)
• run in parallel with enough amount of tasks

[yosukehara]

@mocchira I've tested the latest leo_object_storage on our environment, which has been passed over ten straight times. Thanks for your contribution.

[mocchira]

@yosukehara great to hear that.