Fix uses of "int" where "int64" should be used instead
Fix uses of "int" where "int64" should be used instead

Some structures use int for sizes and UNIX timestamps. On some
platforms, int is 32 bits, so this can lead to the year 2038 issues and
overflows when dealing with large containers or layers.

Consistently use int64 to store sizes and UNIX timestamps in
api/types/types.go. Update related to code accordingly (i.e.
strconv.FormatInt instead of strconv.Itoa).

Use int64 in progressreader package to avoid integer overflow when
dealing with large quantities. Update related code accordingly.

Signed-off-by: Aaron Lehmann <8ecfc6017a87905413dcd7d63696a2a4c351b604@docker.com>

thaJeztah/engine-api,mikedougherty/engine-api,jwhonce/engine-api,docker/engine-api,rhatdan/engine-api,msabansal/engine-api,vdemeester/engine-api