Refactoring of the TriblerNetworkRequest

[drew2a]

Related to #7187

The main changes in this PR are the following:

1. It fixes small logic mistakes in methods TriblerNetworkRequest.on_finish() and TriblerNetworkRequest.cancel()
2. It removes automatic request addition in the constructor of a TriblerNetworkRequest. This change opens an opportunity to write correct tests for TriblerNetworkRequest.

Minor changes:

1. Renamed and replaced TriblerNetworkRequest and TriblerRequestManager.
2. Extended logging.

The PR looks huge but it is mostly because the way how a TriblerNetworkRequest should be added to TriblerRequestManager has been changed.

From

Request()

To

request = Request()
manager.add(request)

[ichorid]

For the love of Guido, why not just manager.add(Request())?! 🤯

[drew2a]

@ichorid

For the love of Guido, why not just manager.add(Request())?! 🤯

There are always several ways of writing code.

I used this example above because it better describes the actual change.

And anticipating your next question. This is:

        request = Request(
            endpoint="ipv8/asyncio/drift",
            on_finish=self.on_ipv8_health_enabled,
            data={
                "enable": True
            },
            method=Request.PUT
        )

        request_manager.add(request)

better than:

        request_manager.add(
            Request(
                endpoint="ipv8/asyncio/drift",
                on_finish=self.on_ipv8_health_enabled,
                data={
                    "enable": True
                },
                method=Request.PUT
            )
        )

[ichorid]

Even in cases like this?

        request = Request("statistics/tribler", self.on_tribler_statistics)
        request_manager.add(request)

vs

        request_manager.add(Request("statistics/tribler", self.on_tribler_statistics))

To me, the second one reads almost like natural text.

[drew2a]

Even in cases like this?

Yes.

[drew2a]

@kozlovsky thank you for the detailed feedback and for refining the code 🤝