Peers screen: Improve responsive display

[jessicaschilling]

The problem

The current-state Peers screen looks fine at wide desktop resolutions (below, 1440px wide) ...

However, both the map and the peers table deteriorate significantly at narrower widths, regardless of height:

• 768px wide (table columns start to break):
  
• 425px wide (map cropped horizontally, table unusable):
  

Additionally, map display degrades substantially at non-16x9ish aspect ratios due to the map dimensions being pegged to percentage of total screen height:

• 1024x385 (map unusably small, gets lost in its surrounding white space):
  
• 320x911 (map unusably cropped):
  

Need in brief

Improve the responsive display of the Peers screen so both the map and the table are as functional at mobile widths and unusual aspect ratios as they are in the standard 16x9, 1440px+ display. This is likely to (but will not necessarily) include:

• Mobile-friendly (e.g. pinch + scale button) zoom/pan controls for peers map
• Side-scroll for peers table

Please note that react-virtualized is used not only for the table on the Peers screen, but also for tables on other screens of the app. If replacing react-virtualized is part of a proposed solution, please also solve for how to implement elsewhere in Web UI.

Acceptance criteria

Solution must ...

• Not sacrifice any functionality of full-sized display
• Gracefully adjust when aspect ratio and display dimensions are resized (e.g. from portrait to landscape on a phone/tablet)
• Display gracefully at and between the following display widths:
  • 320x568 (small phone portrait)
  • 568x320 (small phone landscape)
  • 375x667 (medium phone portrait)
  • 667x375 (medium phone landscape)
  • 414x736 (large phone portrait)
  • 736x414 (large phone landscape)
  • 768x1024 (small tablet portrait)
  • 1024x768 (small tablet landscape)
• Display as gracefully as possible at extreme desktop-browser-window aspect ratios (e.g. but not limited to 400x1200, 1200x400, etc)

[jessicaschilling]

@lidel and @rafaelramalho19 -- thoughts on this issue's definition and acceptance criteria for potential inclusion on the bounty board?

[lidel]

@jessicaschilling apologies, missed this one. I think this makes a perfect bounty, but to avoid duplicated work, would wait until we land #1602/#1616, and then see if acceptance criteria still make sense with the more dense table.

[jessicaschilling]

+1. I suspect we'll need side-scroll on this table regardless of where we come out with those issues, but good plan.