Implement audio player for audio file attachments in Chat (#618)

[oogxdd]

Resolves #618

Synopsis

Сделать: отображение аудио файлов в виде плеера с возможностью аудио воспроизвести, покрыть интеграционным тестом.

Solution

• PlayableAsset виджет расширить и произвести его редизайн под описанные выше необходимости.
• Реализовать фичу: Файл ремоутный (FileAttachment) и файл локальный (LocalAttachment) должны иметь возможность идентифицироваться как аудио, чтобы в списке прикреплений отображаться в виде плеера.
• Для воспроизведения аудио использовать AudioUtils класс. Завести в данном классе какое-нибудь поле или метод, которое бы гарантировало воспроизведение только одного аудио каким-нибудь образом.
• Для покрытия тестом написать мок AudioUtils. который будет подтверждать тот факт, что вызов к аудио был совершён, через соответствующие степы.
• Написать тесты
• Написать документацию

Checklist

• Created PR:
  • In draft mode
  • Name contains issue reference
  • Has type and k:: labels applied
• Before review:
  • Documentation is updated (if required)
  • Tests are updated (if required)
  • Changes conform code style
  • CHANGELOG entry is added (if required)
  • FCM (final commit message) is posted or updated
  • Draft mode is removed
• Review is completed and changes are approved
  • FCM (final commit message) is approved
• Before merge:
  • Milestone is set
  • PR's name and description are correct and up-to-date
  • All temporary labels are removed

[oogxdd]

FCM

Introduce AudioPlayer to the app (allow to play attached audio files)

- Implemented common `AudioPlayerInterface` to provide unified API to work with both `just_audio.AudioPlayer` and `media_kit.Player`
- Created `AudioPlayerController` which acts as a state and methods wrapper for AudioPlayer functionality
- Added `AudioAttachment` widget which displays audio files and allows to play them

[oogxdd]

@SleepySquash В целом готово к ревью. Единственное, пока без тестов.

Несколько комментов.

1. Создал единый интерфейс AudioPlayerInterface для media_kit и just_audio плееров. Потом можно будет дополнять функционалом по типу addToPlaylist, setShuffleMode, etc.

2. Уже имеющийся метод play в AudioUtils не стал использовать, потому что он создает новый инстанс плеера для каждого звука, а нам в аудио плеере это не нужно (потому что нужно будет проигрывать плейлисты етц). По-хорошему было бы отрефакторить AudioUtils полностью, но пока до этого не дошел.

3. Пока что реализовал через GetxController (AudioPlayerController). Мне как программисту с бэкграундом в React/Redux это решение кажется логичном, но если вы считаете что это bad practice - переделаю на воркер (или просто создам дополнительный класс в audio_utils).

4. Сейчас инициализирую контроллер при заходе на страницу чата, и убираю при выходе. В будущем, когда будет делаться глобальный плеер, надо будет перенести это в другое место.

5. Думаю на бэкенде нужно добавить новый филд duration для аудио файлов (и компьютить его при получении файла). Потому что насколько я понимаю нет простого способа высчитать дюрейшен не прогружая файл библиотеками по типу just_audio.

[SleepySquash]

Идея с интерфейсом классная. Я бы предложил, правда, перенести определение, какой плеер должен быть создан, в AudioUtils каким-нибудь отдельным методом. Примеры, как такой getter/метод бы выглядеть:

class AudioUtilsImpl {
  ...
  
  AudioPlayerInterface get player { ... }
  AudioPlayerInterface create() { ... }
  AudioPlayerInterface construct() { ... }
  
  ...
}

Аргумент такого переноса - инкапсуляция. Получится так, что за прямую работу с аудио, даже определение того, какой плеер должен быть создан, отвечает AudioUtils.

[SleepySquash]

@oogxdd, просьба сориентировать по дедлайну, Вы переносили срок на вчера.

[oogxdd]

@SleepySquash

Добрый день. По поводу ПР:

мне потребуется пара часов чтобы заресолвить оставшиеся комменты и еще какое-то время чтобы покрыть тестом. Получится ли дедлайн на завтра перенести, чтобы не сгорел таск?

[SleepySquash]

@oogxdd, не возражаю, хорошо.