Potentially Inconsistent Coordinate Slicing

[dimitribouniol]

Replaced potentially unexpected accesses to coordinate slices with consistent ranges no matter if the raw representation is a root or a slice of data.

Checklist

• I've run tests to see all new and existing tests pass
• I've followed the code style of the rest of the project
• I've read the Contribution Guidelines
• I've updated the documentation if necessary

If you've made changes to gyb files

• I've run .script/generate_boilerplate_files_with_gyb and included updated generated files in a commit of this pull request

Motivation:

As discussed in slack, .prefix(upTo:) and .suffix(from:) are problematic when you don't know the origin of Data, as a slice of Data can have a non-zero startIndex, causing downstream misalignment. For myself, this happened when I tried accessing the rawRepresentation of an ECDSA's PublicKey, which was derived from the x963 representation, and thus had a start offset of 1. Although the code performed as expected, this seemed like a mistake waiting to happen as changing how rawRepresentation is derived for signatures could cause a similar headache in the future, especially so for anyone reading the code as a reference (it me!).

Modifications:

Since the use cases here were to split the Data in half, I replaced the uses of .prefix(upTo:) and .suffix(from:) with .prefix() and .suffix() respectfully.

Result:

No change to behavior, but more semantically correct code.

[Lukasa]

Thanks @dimitribouniol! ✨