edge-http: make fields in {Req,Resp}Headers non-optional

[showier-drastic]

Ensures that the {Req,Resp}Headers is always complete and adheres to the HTTP spec. Saves a lot code from dealing with Options.

Also, send_status_line is removed, and inlined into send_request and send_status. This cuts ~80 lines from the code, which is nice.

[ivmarkov]

My main concern is as expressed below - we are deepening an already existing memory consumption problem. Headers, with N = 60 is 60*8 = 480 bytes, which when created in a future often double its size due to Rust not being very efficient wr.t. futures' size.

We must have a way to pre-create RequestHeaders and ResponseHeaders, or else we won't be able - in future - to pre-create them outside the async code and then possibly pool them. We are also removing this existing option for users who would like to do it, and who are not using the Connection machinery altogether.

[showier-drastic]

Thanks for the review! I understand your point. I would like to know, in the first place, do you think that making the fields non-Option makes sense? If yes, then maybe I can spend some time to think about how to let the user allocate them before parsing.

[ivmarkov]

Thanks for the review! I understand your point. I would like to know, in the first place, do you think that making the fields non-Option makes sense? If yes, then maybe I can spend some time to think about how to let the user allocate them before parsing.

It certainly makes the code simpler and easier to reason about. (My one little concern is the Method field, where I'm not sure we have - in the Method enum, all HTTP 1.1 methods, but I guess that can be double-checked and fixed if methods are still missing. Or maybe we can introduce an Unknown method?)

Otherwise - between introducing something like RequestLine and wrapping this whole thing in an Option (but then, would the code become any shorter than it is now?) - and just using default values for http11 and Method (ditto for the status line case) I don't think there are that many options? And if we use default values, would that be a net win? Maybe, not sure.

Open to any other suggestions though.

[showier-drastic]

This might indeed be unsolvable, other than using MaybeUninit, which is unsafe and does not look worthwhile to be used here.

How about this:

• Remove Options as in this PR;
• Give some default values in new, rather than None;
• Let receive to be an instance method (same as the current master branch) to avoid allocation problem.

[ivmarkov]

This might indeed be unsolvable, other than using MaybeUninit, which is unsafe and does not look worthwhile to be used here.

How about this:

• Remove Options as in this PR;
• Give some default values in new, rather than None;
• Let receive to be an instance method (same as the current master branch) to avoid allocation problem.

I don't see any other way either.
For default values, how about:

• HTTP/1.1
• Method::GET (Or Uknown, if we ever introduce it)
• Status code... 0?

[ivmarkov]

Please restore all const constructors and the calls to those. :-)

The rest looks fine.

[showier-drastic]

Did not know this about new vs default and the relationship to const. Really learned a lot :)