Add SNI to protocols.csv

[MarcoPolo]

This registers the SNI component which can be used by transports to set the sni field in their client hello. See RFC 6066 section 3 for more details.

We need this so that secure websocket clients can know what SNI to send when connecting to an ip address.

[marten-seemann]

Isn't it great that we use base 10 here and base 16 in go-multiaddr? 🥺

[mxinden]

This change looks good to me.

As far as I can tell, this is missing an update to https://github.com/multiformats/multicodec/blob/master/table.csv, correct? @MarcoPolo can you do the update?

---

On a general note, I would suggest keeping pull requests open for longer than 12h before merging. That would allow everyone in the community to comment, no matter which timezone they are in. Based on past experience, pull requests to multiformats/multiaddr are usually not urgent, thus the delay would not hurt productivity.

Would folks agree with the above suggestion?

[MarcoPolo]

As far as I can tell, this is missing an update to https://github.com/multiformats/multicodec/blob/master/table.csv, correct? @MarcoPolo can you do the update?

Ah thanks. I didn't realize we had these two sources of truth. That doesn't seem ideal. I wonder if there's a strategy we can use to keep them in sync. Maybe a CI check in this repo?

On a general note, I would suggest keeping pull requests open for longer than 12h before merging. That would allow everyone in the community to comment, no matter which timezone they are in.

Sounds good to me. What should the timeout be? 24 hours?

This change I considered pretty uncontroversial because there's been an sni example in the readme for 5 years. So it's more surprising that this didn't already exist. But in general I agree.

I'll make a PR template to make these things explicit.