fix: update num_cpus to 1.13.1 to fix cgroup parse problem

[PureWhiteWu]

num_cpus prior to 1.13.1 has some bugs parsing cgroup config, this PR updates num_cpus to 1.13.1 to fix it.
For more information, refer to seanmonstar/num_cpus#113.

[Darksonn]

We typically set Tokio to depend on the oldest version that:

1. Is semver-compatible with the newest version.
2. Has all of the features used by Tokio.

So in this case it is not clear why we should require the new version. People will get the newest version by default even with our current dependency configuration.

[PureWhiteWu]

We typically set Tokio to depend on the oldest version that:

1. Is semver-compatible with the newest version.
2. Has all of the features used by Tokio.

So in this case it is not clear why we should require the new version. People will get the newest version by default even with our current dependency configuration.

Because the old version has some bug, and the new version fixed the bug.

[Darksonn]

Yes, I understand, but with the current configuration, people can still use the new version - in fact, they are getting the new version by default.

[PureWhiteWu]

Yes, I understand, but with the current configuration, people can still use the new version - in fact, they are getting the new version by default.

If they use --locked, then they may get the old version.
If we update this crate to 1.13.1, is there any risks or cons for us?
This update doesn't affect MSRV.

[Darksonn]

The main con is that we prevent users from choosing to use an older version of num_cpus.

[PureWhiteWu]

The main con is that we prevent users from choosing to use an older version of num_cpus.

Just an inquiry: so we won't update a version of our dependency for bug fixes? Or in what situation we will update our dependency?

[Darksonn]

I think the important thing to note here is that we are talking about increasing the minimum required version of the dependency. We usually only bump the minimum required version in two situations:

1. The dependency released a new breaking change. In this case, we will upgrade to the new major version.
2. Tokio requires some feature that was released in a newer version of the crate, and Tokio will not compile if you are using the old version. In this case, we will bump the minimum required version to the smallest version that has all of the features that Tokio are using from that crate.

Nothing here prevents people from getting the bugfix, and indeed they will get it by default when starting a new project or when they call cargo update.

[PureWhiteWu]

Thanks