GitLab

Bumps [github.com/libp2p/go-libp2p-core](https://github.com/libp2p/go-libp2p-core) from 0.5.1 to 0.5.2.
- [Release notes](https://github.com/libp2p/go-libp2p-core/releases)
- [Commits](https://github.com/libp2p/go-libp2p-core/compare/v0.5.1...v0.5.2)
Signed-off-by: dependabot-preview[bot] <support@dependabot.com>

the first source of the invalid message was _not_ penalized!

thanks travis...

travis, travis, why are you so annoying when it comes to test reliability?

so that sqrt propagation math actually works

* test: score time in mesh

* add TestScoreFirstMessageDeliveries

* rm redundant initialization to zero

* add TestScoreFirstMessageDeliveriesCap

* add TestScoreFirstMessageDeliveriesDecay

* fix comment

* add TestScoreMeshMessageDeliveries

* comments

* add TestScoreMeshFailurePenalty

* add TestScoreInvalidMessageDeliveries

also, TestScoreInvalidMessageDeliveriesDecay

* add TestScoreApplicationScore

* add TestScoreIPColocation

* add TestScoreMeshMessageDeliveriesDecay

* add TestScoreRetention

* try longer interval for TimeInMesh test

we seem to take longer to collect the score on travis,
which causes the score to be outside the expected bounds.
hopefully a longer wait time will give us more wiggle room.
Co-authored-by: Yusef Napora <yusef@protocol.ai>

this is madness, but it keeps happening 1 in 10 times.

10ms don't seem to be enough for travis

Bumps [github.com/ipfs/go-log](https://github.com/ipfs/go-log) from 1.0.3 to 1.0.4.
- [Release notes](https://github.com/ipfs/go-log/releases)
- [Commits](https://github.com/ipfs/go-log/compare/v1.0.3...v1.0.4)
Signed-off-by: dependabot-preview[bot] <support@dependabot.com>

Configure the star with 0 D, to act as a proper bootstrapper

pacify the race detector in travis

probabilities are such that they occasionally fail

otherwise we get a division by zero

somehow it managed to fail on travis

the race detector cries on travis

this things keep hitting the global timeout with all the build time involved