Add IPv6 support for network table

[DL6ER]

By submitting this pull request, I confirm the following (please check boxes, eg [X]) Failure to fill the template will close your PR:

Please submit all pull requests against the development branch. Failure to do so will delay or deny your request

• I have read and understood the contributors guide.
• I have checked that another pull request for this purpose does not exist.
• I have considered, and confirmed that this submission will be valuable to others.
• I accept that this submission may not be used, and the pull request closed at the will of the maintainer.
• I give this submission freely, and claim no ownership to its content.

How familiar are you with the codebase?:

10

---

Add IPv6 support for the network table. This updates the database version to 5.

As we expect an interface to have a number of addresses in the IPv6 world, we introduce a new database table network_addresses with three columns:

1. id corresponds to the id of the network table and, as such, to a unique hardware address.
2. ip contains a given IP address corresponding to the hardware address identified by this particular id
3. lastQuery: Unix timestamp of last query seen from this particular IP address.

Conflict management has been implemented to only update the lastQuery column if a given (id,ip) pair already exists in the database. This avoids multiple entries from the same data.

This is a backend implementation. This frontend needs to be modified as well in order to be able to source the new data. This is not a breaking change as the new version can be used with the current dashboard without any issues.

This template was created based on the work of udemy-dl.

[dschaper]

Can we be sure that the ip utility is installed in every platform?

[DL6ER]

@dschaper Yes, we install it as dependency here or here and use it in the installer here, here, here and in a few other places.

[AzureMarker]

Now that we are storing IPs in the network_addresses table, can we remove the ip column from the network table?

[DL6ER]

Now that we are storing IPs in the network_addresses table, can we remove the ip column from the network table?

Removing a column is only possible by creating a new table, copying all but the ip column to it, removing the old table, and renaming the new table to network. This might take some time (thinking about those users with large deployments like in schools) and the user should better not interrupt this upgrading process.
However, canceling the process will likely only trigger need for support but shouldn't cause harm as the copying step will take the majority of time and is non-destructive.

I also agree that we can create an entry in network_addresses for each device during the upgrade process to have only one source of truth for the addresses.

[AzureMarker]

I got this error when it tried to upgrade the database:

[2019-06-27 22:50:41.131 14380] SQLite3 message: abort at 24 in [DROP TABLE network;]: FOREIGN KEY constraint failed (787)
[2019-06-27 22:50:41.131 14380] dbquery(DROP TABLE network;) - SQL error (19): FOREIGN KEY constraint failed
[2019-06-27 22:50:41.131 14380] check_database(19): Disabling database connection due to error
[2019-06-27 22:50:41.131 14380] create_network_addresses_table(): "DROP TABLE network;" failed!
[2019-06-27 22:50:41.131 14380] Network-addresses table not initialized, database not available

[AzureMarker]

It looks like since we enable foreign keys by default, we need to disable them as part of step one:

1. If foreign key constraints are enabled, disable them using PRAGMA foreign_keys=OFF.

https://www.sqlite.org/lang_altertable.html#otheralter

[AzureMarker]

Approved pending merge conflict resolution.

[pralor-bot]

This pull request has been mentioned on Pi-hole Userspace. There might be relevant details there:

https://discourse.pi-hole.net/t/apple-devices-not-in-network-overview/22177/6

[pralor-bot]

This pull request has been mentioned on Pi-hole Userspace. There might be relevant details there:

https://discourse.pi-hole.net/t/network-table-seeing-clients-as-hostname-of-router-rather-than-devices/31597/7