Minor refactors in e2e crate

[pmikolajczyk41]

1. E2EConfig doesn't need whitelisted_attributes (copied from another macro config)
2. We can reuse subxt Polkadot configuration

[pmikolajczyk41]

I'm getting:

error: cannot find macro `assert_eq` in this scope
 --> tests/ui/trait_def/pass/no-implicit-prelude.rs:4:1
  |
4 | pub trait TraitDefinition {
  | ^^^ help: a macro with a similar name exists: `assert`
  |
 ::: $RUST/core/src/macros/mod.rs
  |
  |     macro_rules! assert {
  |     ------------------- similarly named macro `assert` defined here
  |
  = help: consider importing one of these items:
          std::assert_eq
          core::assert_eq
  = note: this error originates in the derive macro `::scale::Decode` (in Nightly builds, run with -Z macro-backtrace for more info)

error[E0425]: cannot find function, tuple struct or tuple variant `Ok` in this scope
 --> tests/ui/trait_def/pass/no-implicit-prelude.rs:4:1
  |
4 | pub trait TraitDefinition {
  | ^^^ not found in this scope
  |
  = note: this error originates in the derive macro `::scale::Decode` (in Nightly builds, run with -Z macro-backtrace for more info)
help: consider importing one of these items
  |
3 | use core::result::Result::Ok;
  |
3 | use std::result::Result::Ok;

on tests/ui/trait_def/pass/no-implicit-prelude.rs which should compile nicely...

[pmikolajczyk41]

the same error is for the master build: https://gitlab.parity.io/parity/mirrors/ink/-/jobs/3105158

[ascjones]

the same error is for the master build: https://gitlab.parity.io/parity/mirrors/ink/-/jobs/3105158

It must be in the codegen of the new parity-scale-codec

[ascjones]

The building of the contracts at the codegen stage is a legacy of when we required the metadata to generate the contract API. So I wonder whether we should just move the code which builds the contracts to be invoked at runtime rather than in the macro code, which is confusing.

[ascjones]

For tests running all in parallel, this might now result in all tests initially attempting to build the root contract simultaneously. I assume they would all just block on the lockfile while the first one builds, which is okay but negates the point of having the already_built_contracts. This mechanism itself might now be unnecessary since the build now is very fast when there have been no changes so we might even be able to remove this entirely.