Move deposit contract back to this repo

[hwwhww]

Deposit contract was moved to another repo because we wanted to make eth2.0-specs pure with just documents. But after some recent updates (thanks to @protolambda and @djrtwo), now eth2.0-specs repo is the CI/test-gen center. It seems moving deposit contract back can make the spec-syncing and release easier.

[protolambda]

Initially (~month ago) I was looking for solutions to have the generators/tests live elsewhere. They are just too dependent/close with the spec itself, so it made sense to go for a more monorepo-ish approach. We could take it further, and just call this the "eth2" monorepo, with release & unified testing. I'm ok with more things being merged into this repo, but we should also look into alternatives, if there are any. And the net benefits of course.

So, to iterate, current options (with their individual pros/cons) are:

deposit contract in external repo

Pros:

• separate Circle CI
• consistent with structure of other contract-only repositories
• separate documentation dependencies. You use the pandoc tool in the contract repo (?)

Cons:

• needs work/time to get right
• possibly needs new documentation
• a PR label probably helps a lot, but it could be considered "noisy" by some

merge into this repo

Pros:

• monorepo grows, easy to cross-reference things and update things together. (Do we have examples of this from when the deposit contract was hosted here?)
• could integrate it into testing. E.g. local test net + executable spec + simulation -> test behavior

Cons:

• not everyone is a fan of monorepos. Agree in some way, definitely need to keep things organized

Git-submodule one in the other

Not tried before, not sure about net-benefits, not likely to work well.

alternatives?

Suggestions welcome.

[paulhauner]

As a spec consumer, my preference would be for a mono-repo as it would make it easier to locate things and easier to create issues. Additionally, when adding new components its much easier to notice a new dir in an existing repo than a whole new repo.

In my experience, when you're dealing with a big, inter-connected project addressing "issues/PRs clutter" by splitting into separate repos means you have just as many issues/PRs but they're now harder to locate ("which repo was that in again?") or in the wrong place ("this issue should really be on repo X").

Monorepo preference is obviously subjective, just adding my thoughts.

[djrtwo]

I'm pro bringing it back