Don't try to delete keyfile if a non-persistent client tunnel is deleted

[killyourtv]

Scenario: You have a server tunnel configured that has a destkey file i2ptunnel10-privKeys.dat assigned. You also have a client tunnel with i2ptunnel10-privKeys.dat assigned. The client tunnel will not use this key—it's not configured to be persistent. If the client tunnel is deleted the file i2ptunnel10-privKeys.dat will be renamed to i2ptunnel-deleted-$DESC_OF_CLIENT_TUNNEL-$TIME.

Since the client tunnel was not set to be persistent, there wasn't a key to delete/rename…but the key for the server tunnel was renamed instead. Upon the next I2P restart the server tunnel's dest will be different because a new key (to replace the renamed one) will need to be created.

Thankfully the key was not really deleted, it was only renamed so this could be recovered from (assuming the user realizes what happened).

I think it'd be best if we only renamed/deleted the designated client key if it was also set to be persistent.

[kiribati]

Can confirm this. It caused the great "oh shit kiri's tahoe introducer moved" incident of 2012. For details see #tahoe-lafs or URI:DIR2-RO:t4fs6cqxaoav3r767ce5t6j3h4:gvjawwbjljythw4bjhgbco4mqn43ywfshdi2iqdxyhqzovrqazua/introducers on the i2p testgrid.

[zzz]

I can fix the problem as you propose.

The root cause may be, however, that we will pick a privkey file name even if some other tunnel is already using it. The whole automatic file name generation can lead to these and other problems.

Safest thing for now is to always name the server privkey files explicitly when creating the tunnel.

[zzz]

Thanks for the reports.
Fixed in 0.8.12-17-rc as you propose.
There's still some ways to get the privkey files reused or renamed inadvertently but this fixes one of them.

[killyourtv]

I thought that the proposed method would be an easy way to resolve part of the problem (or at least one of the methods of privkey (re)moving) but I didn't realize it'd be a one-line fix.