Remove IP allow-list in frontend until UX is figured out...

[m5nv]

Context Historically the frontend evolved to be a harness to test the resource-server API without any thought given to UX. Now that the resource-server API is done and tested, we have to shift our focus in making the conduits web.app more usable.

Problem It is more likely that a user will want to specify a global allow-list rather than per conduit. We are wasting cycles in trying to determine how the alllow-list should be displayed and managed in the conduit edit/add form.

NOTE: IP allow-list is an optional field in the backend. NOTE: The reason why the allow-list will end up global is because it is meant to support use cases arising in a peering context (P2P, B2B). Such relations are predetermined and managed independent of a conduit.

Solution Remove all frontend code pertaining to IP allow-list. So that developers don't waste time testing a feature that is highly likely to change (from per conduit to a global allow-list).

Acceptance Criteria

• [x] Changes should be isolated to edit/create conduit UI
• [x] Backend code should not be touched to get this to work
• [x] Backend test cases should work with identical results as before
• [ ] Frontend functional test cases should pass
• [x] Manual testing of sign-up/sign-in, and conduit create/edit/delete/list should pass

[kavithaii]

Functional tests are out of my scope. PR #156 or issue #152 will take care of functional tests.

• [ ] Frontend functional test cases should pass