Fix adjacency list serialise types

[andreacassioli]

Try to address this in a more general way.

According to the offical docs the type representing the number of vertices and edges in a graph can be deduced by the graph traits.

IMHO there are two approaches:

1. read/write a fixed integer type to allow different graph types (with potentially different size types) to be used
2. read/write integers that depend on the graph type, loosing potentially some fleibility

I believe the former is the original design. So in this PR

• make sure all read/write serializations are down using unsigned int
• convert the relevant values to the type deduced from the graph traits
• small cleanup modernizing a bit the code

[andreacassioli]

I think this might break compatibility because the size of the integers written and read will depends on the graphs used to read and write. So I believe there is a bit more to do.

[andreacassioli]

@jeremy-murphy there is a failure in the CI that I do not understand, it does seem to be related to my changes. What do you think?

[jeremy-murphy]

@jeremy-murphy there is a failure in the CI that I do not understand, it does seem to be related to my changes. What do you think?

Yeah, that's very odd. Looks like a problem either in Boost.Math or in the system libraries themselves. I would just ignore it for now and hope it goes away by itself.

[jeremy-murphy]

Isn't this going to cause a problem for users with, however unlikely, graphs where vertices_size_type is std::size_t and actually have billions or trillions or vertices?

Also, it would waste space for users that have billions of tiny graphs where they have customized vertices_size_type to be unsigned char, etc?

[andreacassioli]

yeah, I follow the current implementation approach of storing always the same type (i.e. int) so that one can read/write with different graph type. It is indeed a bit wasteful.

Otherwise one could deduce these types fro the traits, assuming that the graph type remains the same. It was actually my first thought.