Add collections crate

[febo]

Problem

Client generation need custom types to support String and Vec to have different prefix length types – e.g., a String with a u8 length prefix or a Vec<Address> without a prefix that consumes the remaining available bytes.

Solution

Add a new crate to include custom String and Vec types with borsh and wincode serialization support.

[febo]

Maybe we should depend on alloc by default so we can avoid having so many #[cfg(feature = "alloc")]. Currently both types require alloc.

[joncinque]

That's fine by me, we could even call the crate spl-alloc if we want to try something else 😅

[febo]

The spl-collections name is experimental.

[joncinque]

Looks great overall! Mostly small points

[joncinque]

That's fine by me, we could even call the crate spl-alloc if we want to try something else 😅

[joncinque]

To go with these changes, can you include the new package at

libraries/.github/workflows/main.yml

Lines 11 to 13 in ed9d43b

	SBPF_PROGRAM_PACKAGES: "['discriminator', 'generic-token', 'list-view', 'pod', 'program-error', 'tlv-account-resolution', 'type-length-value']"
	RUST_PACKAGES: "['discriminator', 'discriminator-derive', 'discriminator-syn', 'generic-token', 'generic-token-tests', 'list-view', 'pod', 'program-error', 'program-error-derive', 'tlv-account-resolution', 'type-length-value', 'type-length-value-derive', 'type-length-value-derive-test']"
	WASM_PACKAGES: "['discriminator', 'generic-token', 'list-view', 'pod', 'program-error', 'tlv-account-resolution', 'type-length-value']"

and

libraries/.github/workflows/publish-rust.yml

Line 12 in ed9d43b

- discriminator

?

[joncinque]

Shouldn't this only read prefix items and not all of them?

[joncinque]

Shouldn't this multiply the length by the size of T?

Suggested change

	Ok(core::mem::size_of::<$prefix_type>() + src.0.len())
	Ok(core::mem::size_of::<$prefix_type>() + src.0.len() * core::mem::size_of::<T>())

[joncinque]

Same with this, shouldn't it only read prefix items?

[joncinque]

Considering String just wraps Vec<u8> under the hood, maybe TrailingString can just wrap TrailingVec<u8> and PrefixedString can just wrap PrefixedVec<u8>, and we can remove a lot of this code, except for a converter to a String and a &str. But if it's too complicated, don't worry about it, this code looks fine to me. What do you think?

[joncinque]

Is this approach fallible? If the reader happens to fill half-way through a multi-byte character, won't this fail? Or is that not possible because BUFFER_SIZE is a nice power of 2?