Fix handling of key attributes with CustomName attributes

[purkhusid]

What?

Fixes an issue where you have an inverted key for a GSI and you are using the CustomName attribute at the same time

[bartelink]

match to avoid the allocation?

[bartelink]

Suggested change

	let rand = let r = Random.Shared in fun () -> int64 <| r.Next()
	let rand = let r = Random.Shared in fun () -> r.Next() |> int64

[samritchie]

Unsure if this is already common library usage but duplicating attributes in a record via CustomName seems odd (especially key attributes) - aside from anything else I don’t know what the expected update behaviour should be. Are you able to go into a bit more detail about where/why you use this?

[purkhusid]

@samritchie I agree, the CustomName attribute does invite some strange usage patterns and the error handling isn't as robust as it would have to be so that the end user falls into a pit of success. Ideally there would just be better validation e.g. if a user sets the CustomName attribute to the same name as another property we need to validate that the values of those properties are equal.
Doing this validation proved harder that anticipated since comparing AttributeValue correctly is a bit painful.

I'm fine with putting this on ice, or maybe just adding a better error messages when this happens. We originally started using this pattern due to not being able to put the main key attributes and the GSI attributes on the same properties but that has been fixed.