les: fix les/1 CHT compatibility issue

[zsfelfoldi]

This trivial PR fixes an off-by-one error converting to and from LES/1 CHT numbers in compatibility mode.

[holiman]

It's a bit difficult to review this, because it's not terribly well documented (e.g. what is the impact of the bug, and why does it do +1/-1 -- if it's ceiling, it looks like it still may do wrong. ceil(a/b) == (a+b-1)/b, not a/b+1 ).

I also see that we stop for a softLimit post-facto; after the soft limit has been broken. I hope there's not an attack vector in there?

[zsfelfoldi]

@holiman CHT tries are generated regularly and are identified by an index. In LES/1 they were generated every 4096 blocks, in LES/2 every 32768 blocks (it was just too much unnecessary overhead, especially because in LES/2 the bloom bit tries were added too). Also (what I forgot to consider at first) LES/1 requests indexed CHTs starting from 1 (so that CHT #1 contained data for blocks up to block 4095, CHT #8 until 32767 (this last block is called the section head). LES/2 indexes CHTs starting from 0 so CHT #0 contains data for blocks up to block 32767. So LES1CHT #8 == LES2CHT #0, LES1CHT #16 == LES2CHT #1, LES1CHT #24 == LES2CHT #2 and so on.
Internally, CHTs are still generated every 4096 blocks to ensure backwards compatibility but according to the new chain indexer mechanism they are numbered from 0 and this is how light.GetChtRoot expects the index. I know it turned out to be a mess but after some time we can remove LES/1 compatibility and simplify this part and always use LES/2 indexing everywhere.

[zsfelfoldi]

softResponseLimit was inherited from eth/handler.go and it works exactly the same there too, though I am not 100% sure if we even really need it. The request count limit MaxHelperTrieProofsFetch limits the amount of data anyway, also each individual request can generate a limited amount of response data so I see no attack vector here.
We can discuss whether we should remove softResponseLimit but that is outside the scope of this PR.

[karalabe]

Could we somehow have a test for this? Would be nice to prevent future regressions.