Make config.MaxLogCalls dependant on some consensus param

[algorandskiy]

Summary

• Commented some constants in teal evaluator and added a test
  enforcing their values and directing on how to change them if/when needed.

Test Plan

Existing tests

[codecov-commenter]

Codecov Report

Merging #2732 (e6b06fa) into master (58bc231) will decrease coverage by 0.00%.
The diff coverage is 0.00%.

@@            Coverage Diff             @@
##           master    #2732      +/-   ##
==========================================
- Coverage   47.09%   47.09%   -0.01%     
==========================================
  Files         350      350              
  Lines       56309    56309              
==========================================
- Hits        26520    26519       -1     
  Misses      26817    26817              
- Partials     2972     2973       +1     

Impacted Files	Coverage Δ
config/consensus.go	84.01% <ø> (ø)
data/basics/msgp_gen.go	35.46% <0.00%> (ø)
data/basics/teal.go	38.61% <ø> (ø)
data/transactions/logic/eval.go	90.61% <ø> (ø)
ledger/blockqueue.go	81.03% <0.00%> (-4.03%)	⬇️
catchup/service.go	68.57% <0.00%> (-1.56%)	⬇️
ledger/acctupdates.go	62.55% <0.00%> (-0.09%)	⬇️
data/transactions/verify/txn.go	45.08% <0.00%> (ø)
network/wsNetwork.go	61.11% <0.00%> (+0.18%)	⬆️
network/requestTracker.go	71.12% <0.00%> (+0.43%)	⬆️
... and 2 more

---

Continue to review full report at Codecov.

Legend - Click here to learn more
Δ = absolute <relative> (impact), ø = not affected, ? = missing data
Powered by Codecov. Last update 58bc231...e6b06fa. Read the comment docs.

[jannotti]

I don't want to move this one variable out when all the nearby values are of the same variety - they are not consensus parameters, rather they are conservative esitmates of the largest that some encoded message part can be. It's not just this variable that is like that.

[algorandskiy]

The problem with other values they are derived from consensus param, and this one is not because MaxLogCalls not in consensus. In fact it should not be even called Max...

[jannotti]

By not using the same variable, the MaxEncodedTealLogCalls becomes completely "invisible". A reasonable person might make it so that teal v6 allows more logs calls, but preserves compatibility for v5 and below. They would not even know there is a place where we put alloc bounds on it.

Here's an entirely different proposal that I think is simple, correct, and the same as what we do elsewhere. Notice how we set the bounds on deltas:

	// These bounds could be tighter, but since these values are just to
	// prevent DoS, setting them to be the maximum number of allowed
	// executed TEAL instructions should be fine (order of ~1000)
	checkSetMax(p.MaxAppProgramLen, &MaxStateDeltaKeys)
	checkSetMax(p.MaxAppProgramLen, &MaxEvalDeltaAccounts)
	checkSetMax(p.MaxAppProgramLen, &MaxAppProgramLen)

This is wildly bigger than it needs to be, but we're only trying to avoid crazy huge DoS messages. So let's just set the bound on MaxLogCalls the same way. Add:
checkSetMax(p.MaxAppProgramLen, &MaxLogCalls)

Now it's derived from consensus and doesn't need to be revisited.

Although we have another problem - nowadays, I suppose these bounds are not as obviously correct as they used to be. You could loop, setting many keys, perhaps more that 1000. We could use the MaxAppCost, rather than MaxAppLen though, since that's what would stop us. (Though it would need to be MaxGroupSize*MaxAppCost. because of pooling)

[algorandskiy]

Looks reasonable, done

[jannotti]

Seems good, glad we found middle ground.

[shiqizng]

look good to me