Add a test to verify MAX_SUBSCRIBED_TOPICS constant

[StefanBratanov]

PR Description

Instead of hardcoding, we can compute MAX_SUBSCRIBED_TOPICS based on the highest supported milestone.

Fixed Issue(s)

N/A

Documentation

• I thought about documentation and added the doc-change-required label to this PR if updates are required.

Changelog

• I thought about adding a changelog entry, and added one if I deemed necessary.

[zilm13]

I'd oppose this:

1. You should keep subscribed to the topics on previous fork for 2 epochs. So the actual number is sum and it hits cap when you have forks one by one. It could be the sum of the 3.
2. Less code is better code
3. We don't pay for big hardcoded number, it has 0 memory or whatever consequences

[zilm13]

Ahh I see, you multiply by 3, but we have no guarantee that fork-1 has less topics. So it's just another place for a new bug

[zilm13]

What I think we could keep - test that highest fork + (fork-1) + (fork-2) topics is less than hardcoded number. So it will fail in future if we hardcode something not enough today.

[StefanBratanov]

What I think we could keep - test that highest fork + (fork-1) + (fork-2) topics is less than hardcoded number. So it will fail in future if we hardcode something not enough today.

I like the idea of a test actually more!

[tbenr]

I like the test-only approach :)

[zilm13]

LGTM
but if I turn on super-paranoid mode, I'd find max of all forks first and then multiply by 3.