Remove hardcoded storenodes from status-go

[richard-ramos]

In services/mailservers/fleet.go a list of storenodes is hardcoded, we should come up with a solution that does not involving harcoding the node multiaddresses in the code.

Some stuff to take into account:

1. Using only a DNS Discovery URL to retrieve the storenodes might not be a good solution: we'd likely need to have the list of storenodes somewhere, for example, either by using multiaddresses with ip Addresses instead of domain names in the node config or via discv5?
   It has happened before that core contributors have had problems with their DNS for some reason, and then the core contributor couldn't retrieve the bootnodes and ended up with 0 peers. If the same situation happened with the storenodes dns discovery url, it would mean that no history nodes would be available for the user

2. At the moment of writing this issue, status uses an specific list of storenodes, with 30d of history and high availability. We cannot use discv5 and request history from any storenode we find with Discv5 because there is no guarantee that the node will have the message history. If we use discv5, we'd likely have to compare the peerID of the discovered nodes with a list of trusted nodes to make sure we use specific store nodes. Using discover is also problematic because the way status works right now, it will not request history for a period of time that it has already requested the history before, so if we choose a random storenode and we request history for some time interval, and that storenode has no data for that interval, then, the client will no longer attempt to retrieve history for that period of time.

[fryorcraken]

Do we need this for reliability? This seems to be necessary if:

• we want to deploy a new fleet
• we want community owners to self host

None are planned on the short term so I would suggest to icebox this for now, focus on reliability

[jakubgs]

It does in the sense that it allows use to scale up the fleet and the apps should pick that up based on updated ENRTrees, rather than have to release a new application to update the hardcoded list of nodes.

[fryorcraken]

@richard-ramos are we using ENR tree as well for store node or not at all?

[richard-ramos]

No. We use only ENRs and Multiaddresses:
https://github.com/status-im/status-go/blob/develop/services/mailservers/fleet.go#L20-L21