Rename "input relays" as "portals"

[ZzzzHui]

As we are removing application address relay in this PR, now the only type of input relay is the asset portals. So I think we don't need to introduce a new term "relay" to refer to basically "portals". We could rename relay to portal.

The only places relay appears are for InputRelay. So I started thinking about the necessity of having the InputRelay interface/contract. What InputRelay has is essentially a state var inputBox and a getInputBox function. The steps are:

1. remove InputRelay interface/contract
2. add getInputBox function to portal interfaces
3. add state var _inputBox and getInputBox function to portal contracts

What do you think?

[guidanoli]

If we removed the IInputRelay interface and InputRelay contract, we would be introducing code duplication on purpose on several contracts and interfaces. Furthermore, it's good to have a common interface amongst all input relays, so that we can properly type the getInputRelays function on the IApplication interface. Therefore, I think we shouldn't pursue this direction.

[ZzzzHui]

If we removed the IInputRelay interface and InputRelay contract, we would be introducing code duplication on purpose on several contracts and interfaces.

Yeah. It's a tradeoff between having code duplication and having one more layer in codebase structure.

Furthermore, it's good to have a common interface amongst all input relays, so that we can properly type the getInputRelays function on the IApplication interface.

This is a good argument. IInputRelay is a better common interface than IERC165.

In conclusion, this issue will only do the renaming

[guidanoli]

In conclusion, this issue will only do the renaming

You mean, substitute "input relay" by "portal"?

[ZzzzHui]

Yeah. IInputRelay -> IPortal InputRelay -> Portal And move those 2 files from the folder inputs to the folder portals What do you think?

[guidanoli]

Adjusted this issue's name to reflect our decision.