G1: Investigate removal of maintenance of two BOT thresholds

G1 maintains two thresholds in G1BlockOffsetTablePart indicating where the next BOT entry will be placed (or iow, the last + 1 written entry): once as an index into the BOT, once as a direct pointer to the BOT entry in the BOT (_next_offset_index and _next_offset_threshold respectively).

This seems unnecessary as derivation of one from the other seems simple enough, and it also prevents update of that threshold atomically. I.e. currently, if there is the question for the start of a block (block_start()) of an address beyond _next_offset_index from the GC, G1 will update the BOT itself to that location, but will not update _next_offset_index/_next_offset_threshold. This means that the next similar question will cause recalculation of the BOT over and over again.

Note that
a) updates to the BOT below _next_offset_index/_next_offset_threshold work as expected,
and b) it is unknown whether this is a useful use case, i.e. "common"

There is no known failure (or rather slowdown) because of this; one potential improvement could be made for full gc, where we currently need to update the thresholds for not-compacted young regions anyway (see JDK-8264987; but in this case we may rather want to penalize full gc anyway instead of in the worst case the young gc card table scan doing this).