chore: add portal-spec-tests repo as submodule

[morph-dev]

What was wrong?

We couldn't use files from ethereum/portal-spec-tests directly in our tests. See: #1129

How was it fixed?

• Added portal-spec-tests as submodule
• Refactored tests in ethportal-api/src/types/content_value/state.rs to use those files instead
• Updated .circleci/config.yml to add support for submodules (instructions)

fix: #1129

To-Do

• Clean up commit history and use conventional commits.

[njgheorghita]

It would be useful to include the basic instructions for using submodules (eg. init / update) in the README file as a reference. Basically what you posted in the trin discord channel

[morph-dev]

Created dedicated page in the book. Added short info and link to the README.

[njgheorghita]

I'm sure this value will eventually be shared w/ other locations in the code. I'd recommend creating a ethportal-api/src/constants.rs module to locate this value. Also, maybe change the var name to PORTAL_SPEC_TESTS_SUBMODULE_PATH to be a bit more explicit in what it's pointing towards?

But... maybe it makes more sense to do something like ...
in ethportal-api/src/constants.rs

pub const PORTAL_SPEC_TESTS_SUBMODULE: &str = "../portal-spec-tests";

and then here, import PORTAL_SPEC_TESTS_SUBMODULE and ...

const TEST_DATA_DIRECTORY = "/tests/mainnet/state/serialization";

and then join the values here? Since, it's likely other locations will want the path to the specs submodule, but don't necessarily want the same folder

[morph-dev]

I created src/test_utils/* and put it there, together with functions that reads file as string (less boilerplate everywhere).

I decided against ethportal-api/src/constants.rs because that feels like a file that maybe we want to export publicly (as a crate), while this constant wouldn't make sense or fit there.

[njgheorghita]

The question I'd ask is, where are we likely to use this constant? According to #1130 we'll need it inside ethportal-peertest, and I know we'll eventually need it inside portal-bridge. So, maybe it makes sense that it's a constant we should export? But also, each workspace that needs assets from portal-spec-tests can define it's own constant inside it's own workspace...

I'm undecided honestly, and it doesn't feel like a make or break decision here. So, let's just move ahead as is

[morph-dev]

My worry is about its value to the crates that import it outside of this repo, like glados and portal-hive. It would just be meaningless in that scenario.

But considering that most frequent usage comes from this repo, I understand your point as well. And same as you, I'm undecided.

With that being said, I still prefer it in a test related path (not ethportal-api/src/constants.rs). And if we decide to export it, we can just export it from there.

[morph-dev]

Rebased to head and cleaned up commit history.

[ogenev]

LGTM 👍