s2n-tls server reports signature scheme for TLS1.2 session resumption

### Security issue notifications

If you discover a potential security issue in s2n we ask that you notify
AWS Security via our [vulnerability reporting page](http://aws.amazon.com/security/vulnerability-reporting/). Please do **not** create a public github issue.

### Problem:

Like https://github.com/aws/s2n-tls/issues/5477, we also incorrectly report a server signature for TLS1.2 session resumption.

See s2nd output:
```
s2nd localhost 8000
libcrypto: AWS-LC 1.49.1
Listening on localhost:8000
CONNECTED:
Handshake: NEGOTIATED|FULL_HANDSHAKE|TLS12_PERFECT_FORWARD_SECRECY|WITH_SESSION_TICKET
Client hello version: 33
Client protocol version: 33
Server protocol version: 33
Actual protocol version: 33
Server name: localhost
Curve: secp256r1
Cipher negotiated: ECDHE-RSA-AES128-GCM-SHA256
Server signature negotiated: RSA-PSS-RSAE+SHA256
Early Data status: NOT REQUESTED
JA3: 736793ccdc2f357bd358e78e28f849ba
Wire bytes in: 302
Wire bytes out: 3024
s2n is ready
CONNECTED:
Handshake: NEGOTIATED
Client hello version: 33
Client protocol version: 33
Server protocol version: 33
Actual protocol version: 33
Server name: localhost
Curve: secp256r1
Cipher negotiated: ECDHE-RSA-AES128-GCM-SHA256
Server signature negotiated: RSA-PSS-RSAE+SHA256 <--- NOT CORRECT
Resumed session
Early Data status: NOT REQUESTED
JA3: 736793ccdc2f357bd358e78e28f849ba
Wire bytes in: 365
Wire bytes out: 147
s2n is ready
```

As opposed to s2nc:
```
s2nc localhost 8000 -r
libcrypto: AWS-LC 1.49.1
CONNECTED:
Handshake: NEGOTIATED|FULL_HANDSHAKE|TLS12_PERFECT_FORWARD_SECRECY|WITH_SESSION_TICKET
Client hello version: 33
Client protocol version: 33
Server protocol version: 33
Actual protocol version: 33
Server name: localhost
Curve: secp256r1
Cipher negotiated: ECDHE-RSA-AES128-GCM-SHA256
Server signature negotiated: RSA-PSS-RSAE+SHA256
Early Data status: NOT REQUESTED
Wire bytes in: 3024
Wire bytes out: 302
s2n is ready
Connected to localhost:8000
CONNECTED:
Handshake: NEGOTIATED
Client hello version: 33
Client protocol version: 33
Server protocol version: 33
Actual protocol version: 33
Server name: localhost
Curve: NONE
Cipher negotiated: ECDHE-RSA-AES128-GCM-SHA256
Server signature negotiated: None+None <--- CORRECT
Resumed session
Early Data status: NOT REQUESTED
Wire bytes in: 147
Wire bytes out: 365
s2n is ready

```

This is not a problem for TLS1.3. I confirmed that with both the code and s2nc/s2nd.

### Need By Date:

None, no customer reach outs. I think this is just a visibility / logging / metrics issue.

### Solution:

Like https://github.com/aws/s2n-tls/issues/5477, don't choose a signature scheme if resuming a session. It might be a little trickier though, since I don't think we actually decrypt + confirm the session until after we choose a signature scheme. We might have to reset the signature scheme instead.

### Requirements / Acceptance Criteria:

What must a solution address in order to solve the problem? How do we know the solution is complete?

* **RFC links:** Links to relevant RFC(s)
* **Related Issues:** Link any relevant issues
* **Will the Usage Guide or other documentation need to be updated?**
* **Testing:** How will this change be tested? Call out new integration tests, functional tests, or particularly interesting/important unit tests.
* **Will this change trigger SAW changes?** Changes to the state machine, the s2n_handshake_io code that controls state transitions, the DRBG, or the corking/uncorking logic could trigger SAW failures.
* **Should this change be fuzz tested?** Will it handle untrusted input? Create a separate issue to track the fuzzing work.

### Out of scope:

Is there anything the solution will intentionally NOT address?

[//]: # (NOTE: If you believe this might be a security issue, please email aws-security@amazon.com instead of creating a GitHub issue. For more details, see the AWS Vulnerability Reporting Guide: https://aws.amazon.com/security/vulnerability-reporting/ )

Start by comparing the TLS1.2 resumption behavior in s2nd and s2nc, and review related issue 5477. Trace where the server signature scheme is selected relative to session decryption and resumption confirmation. Done means resumed TLS1.2 sessions report no server signature scheme, with tests covering the corrected output; check whether state-machine or SAW tests are affected.

Written by the indexing model from the issue text.