Ethereum Classic should be considered mainnet

[fish-sammy]

The Ethereum classic network should be considered a mainnet and therefore bump up the cache size if necessary. I am not quite sure about Social network, EtherSocial network and Mix network so let me know if they shouldn't.

[meowsbits]

The reason for bumping the cache on ETH is to improve performance in the context of usually full block blocks (and thus relatively strenuous disk IO, which is mitigated with LevelDB caching). ETC doesn't see this level of activity, and AFAIK nor do Social and Ethersocial, etc.

With this, it should be noted that the code is written in a somewhat misleading/ambiguous way, since the cache bump has nothing to do with Mainnet vs. Testnet per se, rather with anticipated leveldb busy-ness. Unless Classic or Social, etc. see a need to bump cache defaults based on visible performance gains, I'm hesitant to mess with them. (There is, too, a potential resource cost associated with increasing default memory allowances).

In fact, Goerli and Ropsten both see a lot of use, and there might be an argument there to bumping defaults, but, as it were, I'm inclined to leave that decision to the ethereum/go-ethereum maintainers since they're the arbiters of those networks.

@sammy1991106 Do you see a performance issue and/or gain on ETC to reason the default bump contrary to what I have above? If so, I'd be happy to reconsider.

[fish-sammy]

@meowsbits If you think all the other networks except for ethereum mainnet don't have enough traffic to benefit from the cache bump, it's all good. I made this PR because I realized that with the previous PR #145 here, I actually made a difference for networks like ethereum classic mainnet (which was bumped before but not anymore now).

Feel free to close this PR if you think the current behaviour is the best and desired.

[meowsbits]

Thanks @sammy1991106. For now, I'm going to tentatively say it's OK as-is. As above, it might be reasonable to bump the cache on active test nets, but that's out of scope for us (and testnet performance isn't a high priority anyways). And there are a few sections on the ETC chain which would benefit from a higher cache (spam in the 2M- range, dust clearing in the late 8M- range), but without having yet done an analysis on those to understand consequences, I'm inclined to leave for now until we have more information or feedback.

Cheers.