Add support for Postgres inet type

[rausnitz]

We implemented this in our project so we could use the Postgres inet type with PostgresNIO. Postgres's inet and SwiftNIO's SocketAddress aren't a perfect match but they're fairly close.

Let me know if you'd like to have this be a part of PostgresNIO. I also have tests I can port over from our project.

[fabianfett]

@rausnitz Thanks for proposing this. SwiftNIO's SocketAddress is a somewhat special type... It still has some rough C edges.

Besides that, accepting this patch would increase the shared API surface between PostgresNIO and SwiftNIO. However our long term goal is to make SwiftNIO an implementation detail of PostgresNIO. This would be a step in the opposite direction. Because of this I'm inclined to reject this PR. @gwynne WDYT?

[rausnitz]

@fabianfett Yeah, I don't love tying this to SocketAddress here either, though it's nice as a shortcut in our particular project. I stil wonder about the rest of it: Does PostgresNIO have an interest in providing a way to parse the binary representation of types that don't have good Swift counterparts? It seems like a waste that others would have to re-write the code for handling inet data, but I'm not sure what is the place for that in PostgresNIO outside of a PostgresCodable implementation.

[fabianfett]

@rausnitz I think I should rephrase my concerns:

If you implement a PostgresINET type that represents what the Postgres inet type does without depending on NIO, I'll be happy to merge that PR. Does that make sense?

[codecov-commenter]

Codecov Report

❌ Patch coverage is 95.06173% with 4 lines in your changes missing coverage. Please review.
✅ Project coverage is 77.14%. Comparing base (baff615) to head (bb05d6e).
⚠️ Report is 1 commits behind head on main.

Files with missing lines	Patch %	Lines
...es/PostgresNIO/New/Data/Inet+PostgresCodable.swift	95.06%	4 Missing ⚠️

Additional details and impacted files

@@            Coverage Diff             @@
##             main     #413      +/-   ##
==========================================
+ Coverage   77.02%   77.14%   +0.11%     
==========================================
  Files         136      137       +1     
  Lines       10500    10581      +81     
==========================================
+ Hits         8088     8163      +75     
- Misses       2412     2418       +6     

Files with missing lines	Coverage Δ
...es/PostgresNIO/New/Data/Inet+PostgresCodable.swift	95.06% <95.06%> (ø)

... and 5 files with indirect coverage changes

🚀 New features to boost your workflow:

• ❄️ Test Analytics: Detect flaky tests, report on failures, and find test suite problems.

[rausnitz]

If you implement a PostgresINET type that represents what the Postgres inet type does without depending on NIO, I'll be happy to merge that PR. Does that make sense?

@fabianfett Let me know if f972b92 is what you had in mind, and I can add tests if so.

[fabianfett]

I think this is too close to the on the wire representation. In an ideal case this would be closer to the semantical meaning:

struct PostgresIPv4 {
  var value: (UInt8, UInt8, UInt8, UInt8)
}

struct PostgresIPv6 {
  var value: (UInt16, UInt16, UInt16, UInt16, UInt16, UInt16, UInt16, UInt16)
}

enum PostgresINET {
  case ipv4(PostgresIPv4, networkMask: UInt8?)
  case ipv4(PostgresIPv6, networkMask: UInt32?)
}

Since there are no currency types for this in Swift, we need to have our own minimal type for this.

[rausnitz]

@fabianfett Without an explicit isCIDR property, would it be safe to infer that an instance uses CIDR notation based on whether the IPv4 network mask is 32 (or IPv6 network mask is 128)?

[rausnitz]

I took another look at this and figured out why I was confused about the "is CIDR" bool that is required to be sent on the wire along with an inet value. The Postgres code says the value is only there for "historical reasons" and will be ignored. I'll update this PR and submit for re-review soon.

[rausnitz]

@fabianfett I'm ready for another review (a mere 33 months later).