[PAY-1319] Fix emoji keyboard overlapping chat text input

[dharit-tan]

Description

The bug: when switching to the emoji keyboard, the keyboard would slightly overlap the textinput (see linear issue).
Root cause: I discovered that the content inside the KeyboardAvoidingView was offset by 84 pixels, which matches the height of the BottomTabBar. For some reason it thought that it had to avoid that too. I'd gotten lucky by using keyboardHeightOffset and landed on a value that perfectly matched up with 84 pixels, but this was a house of cards. The real solution is to measure the height of BottomTabBar and subtract that from the amount to translate the content of KeyboardAvoidingView by.

EDIT: gonna stick with hardcoding. Also needed to handle ios vs android bottom padding separately for some reason.

This solution feels like a bit much for such a simple thing, open to suggestions. I did start by just hardcoding the height of BottomTabBar (see first commit) but I figured there might be cases where there are extra insets at the bottom of the screen or something, so actually measuring it felt more robust.

I tried a variety of approaches:

• Tried to animate away BottomTabBar the same way we do when opening the NowPlayingDrawer, but KeyboardAvoidingView didn't know about the animations and still thought they were visible.
• Set AppTabBar to return null when the keyboard was visible, but this caused the rive animations in BottomTabBar to run again when they re-entered the screen.
• Tried to figure out how to prevent the animations from running via Rive API but couldn't find a way.

Dragons

Is there anything the reviewer should be on the lookout for? Are there any dangerous changes?

How Has This Been Tested?

https://github.com/AudiusProject/audius-client/assets/3893871/b7001f4a-01fa-4895-9b90-4168cfd3975e

How will this change be monitored?

For features that are critical or could fail silently please describe the monitoring/alerting being added.

Feature Flags

Are all new features properly feature flagged? Describe added feature flags.

[audius-infra]

Preview this change https://demo.audius.co/rt-bottom

[rickyrombo]

Is the bottom tab bar height dynamic? I think if we explicitly set its height to the same constant you use in the chats screen (like in your first commit) we should be good - if anyone wanted to change the height they'd see the constant's usage and would have to adjust it there anyway.

I think what you landed on is probably good too but I'm not sure if it needs to be this dynamic

[dharit-tan]

Is the bottom tab bar height dynamic? I think if we explicitly set its height to the same constant you use in the chats screen (like in your first commit) we should be good - if anyone wanted to change the height they'd see the constant's usage and would have to adjust it there anyway.

I think what you landed on is probably good too but I'm not sure if it needs to be this dynamic

Yep fair enough, it's not dynamic just thought this would be safer. I was worried bottom insets would mess things up on some devices, but looked again and we're probably good.

[dylanjeffers]

Great work!

[piazzatron]

Great find!!

Re: keeping it dynamic or not - if we can show that just setting it as a fixed height works on multiple devices, IMO we should rip out the redux stuff and just use a constant. Every little bit of complexity one can avoid adding is a win :D

(As an aside, for this sort of simple pattern of setting a global var and being able to read from it elsewhere, React context is very nice - you can avoid the whole reducer/action/dispatch song and dance) and just set things directly.

[dharit-tan]

Going to merge the hardcoded version, have the measuring version backed up on rt-bottom-bar-measure if we ever want to go back to it.

[rickyrombo]

Looks good. I'd add the constant as the height of the bottom bar to make it explicitly the same as the constant - that way anyone looking to change the bottom bar height knows to modify the constant