T 072733: Update multipart form request serializer

[bconway99]

• I've read, understood, and done my best to follow the CONTRIBUTING guidelines.

This pull request includes (pick all that apply):

• Bugfixes
• New features
• Breaking changes (Potentially)
• Documentation updates
• Unit tests
• Other

Summary

• With the existing implementation we were having difficulties sending HTTP multipart requests to the RestAPI.
• The issue appeared to be the boundary value that is sent alongside these requests.
• The RestAPI endpoint in question (/Documents/LiabilityRelease?consumerId=[ID]) wasn't accepting the existing boundary value.
• In a multipart request, a boundary acts like a marker for each key/value pair in the request's form data.

Implementation

• This updates the serializer to remove additional boundary content.
• This was done to ensure the endpoint responds successfully.
• In summary this would only affect HTTP multipart requests that leverage MultipartFormRequestSerializer.

Test Plan

• I've marked this as including breaking changes.
• While this is a minor change I don't have visibility of all services/endpoints which leverage MultipartFormRequestSerializer.
• This could potentially break access to certain endpoints if they are expecting the original boundary value.
• If CI or any endpoints break for anyone please let me know.

[plflanagan]

I've left one comment, but I will also leave final approval to others who have more experience with conduit and understand the implications better of changing it.

[asolovev]

Overall seems fine. Added a suggestion about using "Random Unification" methods.
There is also a note in RFC2046

   WARNING TO IMPLEMENTORS:  The grammar for parameters on the Content-
   type field is such that it is often necessary to enclose the boundary
   parameter values in quotes on the Content-type line.  This is not
   always necessary, but never hurts.

It doesn't seem necessary in our case, but if there will be additional problems, we can try it as well or use a longer boundary.