Fix segments

[raymondjacobson]

Description

What is the purpose of this PR? What is the current behavior? New behavior? Relevant links (e.g. Trello) and/or information pertaining to PR?

Spent forever playing with aac encoders, etc. etc. etc. and turns out this is the issue.
Tracks > 1:30 will fail at 10:06 (the 101st segment) because of this line
https://github.com/AudiusProject/audius-protocol/blob/master/creator-node/src/ffmpeg.js#L42
which reads segments from the dir in alphabetical order -- those files will be
000.ts
001.ts
...
100.ts
1000.ts
1001.ts
...
1009.ts
101.ts
...

This as you imagine can break * a lot * of things

We have a few ways we can handle this client side for old tracks, but let's get this in ASAP.

• Manually reorder segments > 100 in length uploaded before this is released
• Stream mp3 variants before this is released
  Either way we should be able to patch this over as soon as we can take this out to prod

Tests

List the manual tests and repro instructions to verify that this PR works as anticipated. Include log analysis if possible.
❗ If this change impacts clients, make sure that you have tested the clients ❗

1. Units
2. On stage cn3 (tested with a track that is messed up on prod)
   ...

❗ Reminder 💡❗:
If this PR touches a critical flow (such as Indexing, Uploads, Gateway or the Filesystem), make sure to add the requires-special-attention label. Add relevant labels as necessary.

[dmanjunath]

🤯 this bug is insane. so theoretically every track that overflows past 3 digit segments experiences this because of the character sort issue?

[raymondjacobson]

🤯 this bug is insane. so theoretically every track that overflows past 3 digit segments experiences this because of the character sort issue?

yep...:(

[raymondjacobson]

🤯 this bug is insane. so theoretically every track that overflows past 3 digit segments experiences this because of the character sort issue?

yep...:(

we could also do a global migration to fix existing tracks on discprov. that could be cool.