Fix archive conversion by increasing space for span id

[replay]

No description provided.

[Dieterbe]

some notes about this bug:

• any span larger than 3600 overflows the 4 bits of space we have for it. in our case that only affects environments with 2h spans, which overflow to pos 2,the spot of the 5s span (which no one uses)
• NewAggregator creates sub-AggMetric's, with an AMKey that has overflowed in case of the 2h spans. the in-memory AMKey is effectively one for 5seconds. the only places where the key is used:
• chunkcache (ephemeral anyway, no prob)
• cassandra data store (oops -> building migration tool)
• metricpersist stream (still looking into ramifications)

metricpersist:

• outgoing: kafka routing not affected (key computed without archive info), but message has wrong key
• incoming:
  • calls AggMetric.SyncAggregatedChunkSaveState with wrong info, will just ignore it (or update the wrong aggregation entry if you had an overlap, which doesn't apply for us)

when deploying fixed version, it won't be aware of any chunks saved,
as long as we have migrated the data, we can just deploy with drop-first-chunk and we should be fine.

[woodsaj]

lgtm