Fix batch size handling during metadata during channel content upload

[kozlovsky]

I spend some time profiling the database access code and noticed that the Tribler application spends most of the time inside db_session wrapped around the process_payload method of MetadataStore.

As it turns out, MetadataStore split objects into batches of very small size, and on my machine typical batch size was just two metadata objects.

MetadataStore determines batch size dynamically depending on the duration of the previous batch execution, but the calculation includes sleep time between batches as well, which skewed results.

I fixed the formula and also restricted the minimum and maximum batch size.

After the changes presented in this pull request, the rate of metadata objects insertion on my machine increased by 23%, from 60.63 objects/seconds to 74.84 objects/seconds for the first 4000 objects loaded after the start of the application.

Over the course of the time the application is running, the speed of inserts execution drops significantly, and this does not depend on the size of the database, but on the time the application is running. This should be the next important topic for research since the drop is quite significant.

[sonarcloud]

Kudos, SonarCloud Quality Gate passed!

0 Bugs
0 Vulnerabilities (and 0 Security Hotspots to review)
0 Code Smells

No Coverage information
0.0% Duplication

[synctext]

After the changes presented in this pull request, the rate of metadata objects insertion on my machine increased by 23%, from 60.63 objects/seconds to 74.84 objects/seconds for the first 4000 objects loaded after the start of the application.

nice! Can we please have a performance graph on Jenkins with the insert speed of the channels? Related to huge item requested 2 years ago, #3971