Rename the built-in CKB node

[Keith-CY]

default node was used to denote the internal ckb node before. There're 2 problems:

1. Name convention of default node is not classical, typically it should be capitalized as Default Node
2. default node is not exactly what it represents, it was meant to be the built-in ckb node. But now, the default node can be modified freely.

To improve the UX, I would suggest

1. Add a network named Internal Node, which is limited to the internal ckb node, as the light client did, Internal Node won't connect to an outside node;
2. Switch to the Internal Node is default node is selected while its name and IP are not changed;
3. If the name/IP of the default node have been changed, it will be treated as user-set network and won't be removed;
4. Remove the default node network once it's not active.

---

This update should be fully delivered to users because it may mislead users that data have been changed unexpectedly.

This update can be published with the new UI and marked as an intentional change for the unified style.

[yanguoyu]

1. Check the network, if the mainnet work information is the same as the default. Rename the name to Internal Node, otherwise, add a network named Internal Node
2. Move Internal Node to the top if they are not.
3. Disable edit the Internal Node node.

[yanguoyu]

We should ignore the network chain and genesisHash change because the network type will change by the current start network.

[Keith-CY]

We should ignore the network chain and genesisHash change because the network type will change by the current start network.

The chain type and genesis hash are decoupled with the name and ip, in which step will they be involved in this update?

[yanguoyu]

We should ignore the network chain and genesisHash change because the network type will change by the current start network.

The chain type and genesis hash are decoupled with the name and ip, in which step will they be involved in this update?

When checking whether the user has changed the default node, we will ignore chain and genesisHash, Neuron changes them.

[Keith-CY]

We should ignore the network chain and genesisHash change because the network type will change by the current start network.

The chain type and genesis hash are decoupled with the name and ip, in which step will they be involved in this update?

When checking whether the user has changed the default node, we will ignore chain and genesisHash, Neuron changes them.

Yes, chain and genesisHash are ignored when checking if the default network option has been updated. The fields to check are limited to name and url

[yanguoyu]

nervosnetwork/neuron#2813

[Danie0918]

Currently there is no restriction on linking users to external nodes here, need to add restrictions like light client nodes.

[Keith-CY]

Currently there is no restriction on linking users to external nodes here, need to add restrictions like light client nodes.

To inform users about this update, a dialog could be displayed when the internal node is selected but an external node is detected, and guide users to add a new network option for the external node.

[Keith-CY]

Currently there is no restriction on linking users to external nodes here, need to add restrictions like light client nodes.

To inform users about this update, a dialog could be displayed when the internal node is selected but an external node is detected, and guide users to add a new network option for the external node.

To be more specific:

1. Show a dialog when the internal node is active but an external node is detected
2. Inform user that Internal node is reserved for the built-in node, if he/she wants to keep using the external one, he/she can switch to another network connection or add a new network connection
3. The network connection list can be listed in the dialog for quick action
4. The add a new network option can be listed to go to the editor quickly

[Danie0918]

Will be fixed in #284