Summary

Micropython builds don't have access to the underlying ESP-IDF DS (Digital Signature Peripheral), which allows to use keys saved in eFuses to retrieve an encrypted private key to then generate a signature for a given payload.
This PR adds an entrypoint to support DS operations from ESP-IDF via esp32.DS, which is added to builds via new board variants for ESPS3:

make BOARD=ESP32_GENERIC_S3 BOARD_VARIANT=SPIRAM_OCT_DS

and

make BOARD=ESP32_GENERIC_S3 BOARD_VARIANT=DS

Other variants and builds don't include DS, as it is a somewhat niche use case.
Having this functionality available allows for device verification/authentication.

Testing

• I built both Octal SPIRAM and regular ESP32 S3 builds with and without DS. It was included conditionally as expected.
• Non S3 builds don't compile DS support.
• e2e testing was performed:
  • Created and burnt HMAC key into ESP32-S3
  • Generated a new RSA key
  • Generate a new DS blob and save it onto the board
  • Sign a test payload using this feature
  • Verify the signature on PC
  • Signature is valid.

Trade-offs and Alternatives

Main tradeoff is a slight increase in build size, which is balanced with increased functionality.
DS support remains fully opt-in.

Generative AI

I used generative AI tools when creating this PR, but a human has checked the
code and is responsible for the code and the description above.

Additional notes

Using this functionality requires building a DS blob that encrypts a private key using the HMAC key burnt into the eFuses in a format that ESP-IDF accepts. I have the python script that generates them but was unsure where to put it, if at all. It was made using the same logic as the ESP-IDF test files for DS.
I also have the testing code I used on the board to perform payload signing using the feature and DS blob.
I think they would be very useful but I'd like some guidance on this.