Prevent segment overwrite in the cloud storage by archivers running on different nodes

[ztlpn]

It is possible that more than one archiver for the same NTP is running concurrently (say, if the leadership quickly transferred to another node and back again). If the ntp log is split into segments differently on these nodes, we can end up in a situation when a segment is overwritten with another segment with the same start offset (and thus the same name) but different last offset. This can lead to a discrepancy between the offset range in the manifest and the actual offset range of the segment data and thus to data loss.

To solve that, we can append a unique suffix to each segment name. A good candidate for this suffix is the term when the archiver acquired leadership (note that it will in general be different from the segment term). Raft guarantees that there is only one leader in each term so this prefix is unique. It is also a small incremental integer that points to the node that initiated the upload (in contrast to e.g. a random suffix which can also guarantee uniqueness). This suffix is then included in the segment metadata in the partition manifest. This way we can calculate the unique segment key from the manifest and the manifest and segment data found at keys derived from that manifest are always consistent.

Backwards compatibility: there won't be archiver term ids in the manifests for the segments uploaded by old redpanda versions. This means that the segment key must be generated the old way.