Rebuild InvalidStorageViewController with Texture

[Kharchevskyi]

This PR rebuild InvalidStorageViewController with Texture. Added UI Guidance

close #766

Tests:

• Does not need tests (refactor only, docs or internal changes)

---

To be filled by reviewers

I have reviewed that this PR... (tick whichever items you personally focused on during this review):

• addresses the issue it closes (if any)
• code is readable and understandable
• is accompanied with tests, or tests are not needed
• is free of vulnerabilities
• is documented clearly and usefully, or doesn't need documentation

[tomholub]

This is an interesting example - I find that the UIKit example was more readable and overall more straight forward. From this perspective, it may make sense to stop writing new controllers in Texture, and start migrating away from it.

I wonder what would it look like in SwiftUI.

[Kharchevskyi]

What if we would need to add one new element for example some extra button between views. We would need to relayout all views accordingly.
With UIKit tableview this would be the same as in this PR but with instead uitableview and manual size calculations

[Kharchevskyi]

I would prefer to move towards swift ui instead of ui kit

[Kharchevskyi]

Initially ui was built by just adding uiviews instead of table view usage, which I think less flexible and reusable.

Also ui will be much slower and less smooth on uikit, due to main thread only usage. And what is much more important - all size calculations for ui elements (for example cell height based on text) should be done manually. This would lead to completely reworking compose flow or any other flow with dynamic height

[tomholub]

Of course we should not be converting from Texture to UIKit, that would be a downgrade.

What would this view look like when implemented in SwiftUI? Could you take a look?

[Kharchevskyi]

This is just one example. For full understanding try for example to rewrite To UIKit - ComposeViewController where not only text cell should calculate size but also recipients part.

[Kharchevskyi]

Sure. Should I try Swift ui in this pr or may I open another issue for this?

[tomholub]

Actually, now is not the best time. In the future, we'll look at SwiftUI separately. So we could proceed with this PR as is.

[ivan-ushakov]

Looks like if we have very long stack trace text here, we will have very long node (big height) and button will be hidden from user. User have to scroll down to see button. In my original version button is always on screen, independent of stack trace node height.

[Kharchevskyi]

Can keep this behaviour, but should we?
Apple Human Interface Guidelines recommends to use table views for scrollable layout. Also it's more common for iOS users to scroll if content is higher than screen size. And it's quite rare to have such long localized description

[tomholub]

The exception that caused us to put this in place was indeed quite long, causing a long scroll.

I guess it's fine if the button ends up on the bottom, where user has to scroll. It's more user friendly when it's on top, but it's not too bad on a screen that should be rarely, if ever, seen.