Db-string-type-cleanup

Blueprint Name: db-string-type-cleanup

Rationale

We use string columns to store a variety of logical datatypes: UUIDs, IP addresses, generic strings, among others.

The current practice is for developers to use SQLAlchemy's `String` datatype directly and specify the desired length each time, e.g. String(255), or String(36).

This has a few problems:

• Typos - For example, https://review.openstack.org/#/c/39296 accidentally changed '255' to '25'. Since these are runtime and not parse-time errors, they are usually difficult to recover from and require further cleanup migrations.

• Unecessary Variance - For example, we have 'String(256)' in places where String(255) was preferable (since that's the de facto standard for generic strings)

• No Physical Storage/Logical Datatype Abstraction - Some databases support certain logical datatypes natively, like UUID. By declaring the columns as strings, instead of say 'UUID', we're tying that column down to a particular underlying storage type. (In fact for IP Addresses and CIDR addresses, we're already using this abstraction.)

Design

The proposal here is to extend the work we did for `IPAddress` and `CIDR` to other logical datatypes that are stored as underlying Strings.

This would mean that instead of developers using SQLAlchemy Strings directly and specifying a length, they would use (or add) a predefined logical datatype from our existing sqlachemy/types.py module.

The following mapping from existing physical datatype to logical datatype is proposed:

Count	Current Physical Datatype	Proposed Logical Datatype
2	String(12)	types.PCIAddress
2	String(5)	types.IPProtocol
2	String(8)	types.PCIDeviceType
4	String(4)	types.PCIVendorID, types.PCIProductID
5	String(39)	types.IPAddress (exists)
7	String(256)	types.String
8	String(43)	types.CIDR (exists)
56	String(36)	types.UUID
388	String(255)	types.String