Exclude some types (e.g. floating point types) from Smithy's sets

The docs for the Set shape should be updated to exclude any member types that don’t have an obvious reasonable notion of equality as an equivalence relation, or it should otherwise explicitly specify such a notion.

Floating point types (float, double) are at least one category, since IEEE 754 floating point numbers equality only forms a partial equivalence relation.

The following minimal model builds fine:

$version: "1.0"

namespace com.amazonaws.simple

use aws.protocols#restJson1

@restJson1
@title("SimpleService")
service SimpleService {
    version: "2022-01-01",
    operations: [
        Healthcheck,
    ],
}

@http(uri: "/healthcheck?fooKey=bar", method: "GET")
operation Healthcheck {
    input: HealthcheckInputRequest,
    output: HealthcheckOutputResponse
}

structure HealthcheckInputRequest {
    member: FloatSet
}

structure HealthcheckOutputResponse {
}

set FloatSet {
    member: Float
}

[adamthom-amzn]

Yes, special care would have to be paid to NaN as Java does with its equals method (specifically calling out hashtables). I don’t think excluding floating point numbers from sets is practical for two reasons.

One is that customers who have no use-case for NaN values who want this functionality will be forced to reimplement this functionality themselves. I think the majority of use-cases customers are using Smithy for will not need to consider NaN. Of course this doesn’t mean we don’t have to consider it; I’d rather we consider it than every service owner.

The second is that this restriction, if I understand it correctly, would not just apply to sets/uniqueItems of floats, but it would also apply to collections of unique documents or structures that contain floats. While you could refuse to support sets of structures that contain a floating point member, I think it would be a surprising restriction for customers who later add a floating point member (especially if the type is shared). And, of course, with documents, they’re open types where we could not do a build-time exclusion of floating point values, so you’d be left with the Rust sSDK refusing to support sets of documents containing floats at runtime, whereas other runtimes would happily accept them unless we forced them not to.

[mtdowling]

Closed by #1106. We realized that sets of structures and unions can be dangerous for clients that drop unknown members. Given that we’ve now removed aggregate types from sets, it made my objections to removing float/double moot since there’s no way someone could accidentally break consumers of their model by adding a float/double to a structure or union.