fix(metadata): mutex for concurrency

[just1not2]

Description

This PR brings a fix for containerd/containerd#11138

It consists in a tiny change of the ttrpc.MD object to make it safer by preventing the access of its content from outside this project and adding a RW mutex.

Release plan

Here are the projects that are consuming ttrpc and need to be updated:

• https://github.com/containerd/containerd
• https://github.com/containerd/otelttrpc

[djdongjin]

Is this suppose to be used like a http.Header where you need to Clone when sharing with other "requests", or suppose to be shared and need a mutex?

[just1not2]

I think both ways are fine and we just need to stick with one, I just think the change will be easier to operate with the mutex solution given that there are MD objects that are mutated with the Set and Append (and setRequest) functions (like here)

[cpuguy83]

This looks more like a mishandling of metadata and not something we should need locks for.

[cpuguy83]

I think if GetMetadata returns a copy instead of the actual map that would resolve this?

[just1not2]

This looks more like a mishandling of metadata and not something we should need locks for.
I think if GetMetadata returns a copy instead of the actual map that would resolve this?

As @djdongjin suggested, I think there are 2 ways of dealing with this issue: we can either make the MD object non-mutable or use mutexes to make sure the projects that are consuming containerd/ttrpc cannot reach concurrent operation issues.

Given that the current implementation already relies on updating the MD objects in place (example here and here), I think it would take less effort to implement the second solution (hence my proposal) but I'm not strongly opinionated on the matter.

I would however not recommend only changing the GetMetadata function as it would not prevent concurrent operation issues from the Set and Append functions and map iterations...