CLOUDSTACK-3774: NPE while creating template from snapshot on a upgraded setup.
After upgrade the SSVM was staying in connecting/alert state. This was because
while handling the processConnect command for ssvm the management server was
trying to template sync. For resource limit calculation it was trying to get the
remote size of the template. If the template was no longer available a number
format exception was thrown. The process connect wasn't getting completed and
the ssvm used to stay in connecting/alert state. While creating template from
snapshot cloudstack looks for up and enabled ssvms and because there wasn't
any available (as the ssvm was in coonecting/alert state) it used to pick the
wrong resource (LocalNfs*Resource) instead of the NfsSecondaryStorageResource.

Fixed the issue by making sure number format exceptions are avoided so that
SSVM moves to the right state.
CLOUDSTACK-4084 Fixed the static nat vm ip address in public ip address table in external network gc

In external network after network GC the network n/w cidr changes.
In this case the static nat enable vm ip also chagnes. So updated the new
vm ip address in user_ip_address table.
add cleanup list

Signed-off-by: Prasanna Santhanam <tsp@apache.org>
CLOUDSTACK-4043
Introduced new column format for volumes as per the hypervisor by joining the storage pool and cluster table. Since pre 4.2 storage pool will always have cluster id populated.
Signed off by : nitin mehta<nitin.mehta@citrix.com>
CLOUDSTACK-4013: [PortableIP] [MultiplePhysicalNetworks] Associate
portable IP is trying to insert network id as physical network id

ensuring network id, physical network id, source network id are properly
set for portable ip in user_ip_address and vlan tables
CLOUDSTACK-4070: upgrade from 2.2.14 to 4.2 is failing with 4.0 VMware SystemVm template not found. Cannot upgrade system Vms

System template upgrade is not required during 4.0 upgrade since we handle the same during 4.2 upgrade. So removing the system template update during 4.0 upgrade.
Cloudstack-4015 No error logged when deleteing all the valns when there are allocateed vnets. Alos not updating the vnet range in physicalnetworks table in the above case.

Signed-off-by: Jayapal <jayapal@apache.org>