[av][android] upgrade exoplayer to 2.18.1

[Kudo]

Why

close ENG-6246

How

• upgrade exoplayer to 2.18.1
• migrate breaking changes
• kotlinize packages/expo-av/android/src/main/java/expo/modules/av/player/datasource/CustomHeadersOkHttpDataSourceFactory.java
• remove android/expoview/src/main/java/versioned/host/exp/exponent/modules/universal/av/CustomHeadersOkHttpDataSourceFactory.kt which is exactly the same to the CustomHeadersOkHttpDataSourceFactory inside expo-av package.

Test Plan

• android unversioned expo go + NCL Video

Checklist

• Documentation is up to date to reflect these changes (eg: https://docs.expo.dev and README.md).
• Conforms with the Documentation Writing Style Guide
• This diff will work correctly for expo prebuild & EAS Build (eg: updated a module plugin).

[linear]

ENG-6246 Upgrade exoplayer in expo-av

There is an incompatible exoplayer issue with react-native-track-player where it bump the exoplayer to 2.18.1 internally. The exoplayer 2.18 also introduced some breaking changes. So we should upgrade the exoplayer version as well as some code in expo-av.

Context: #18937

[mnightingale]

Not sure if its worth doing but the C.TYPE_* => C.CONTENT_TYPE_* would clear some deprecation warnings.

Also should that switch handle C.CONTENT_TYPE_RTSP it was added in 2.14.0, I'm thinking no since it would be a new feature and I don't know what iOS/web would do.

Unrelated to this but is there any disadvantage that this package uses an older version of okhttp compared to the few other packages that use it? Does it increase binary size or anything?

[Kudo]

Not sure if its worth doing but the C.TYPE_* => C.CONTENT_TYPE_* would clear some deprecation warnings.

Also should that switch handle C.CONTENT_TYPE_RTSP it was added in 2.14.0, I'm thinking no since it would be a new feature and I don't know what iOS/web would do.

Unrelated to this but is there any disadvantage that this package uses an older version of okhttp compared to the few other packages that use it? Does it increase binary size or anything?

i'm more to have these as a new task. there're many deprecation warnings. i would prefer to do it together when i get more familiar with exoplayer and expo-av code. in the meantime, welcome for contributions. if you could send us a pr, that's much appreciated.

for okhttp, gradle will only have single okhttp version, so it will use the newer compatible version by default. if i get a chance, i could create a pr to remove the okhttp deprecations first.