Generate request body struct

[rcoh]

Issue #, if available: #29

Currently stacked on #28 but will be unstacked once that lands.

Description of changes:
This PR is split into 2 commits:

1. ecba396 refactors the LibRs generator to support generating private modules
2. c7b9c09 generates Body structure shapes for HTTP based protocols

To enable serialization & deserialization, we generate synthetic structs representing the request body. Currently, the serialization method returns a stub, however, in a subsequent PR, serde will be used to generate actual request bodies.

Full output can be viewed in the build artifact, but as an example:

#[derive(::std::clone::Clone, ::std::cmp::PartialEq, ::std::fmt::Debug)]
pub struct BatchGetItemInputBody<'a> {
    pub return_consumed_capacity: &'a Option<ReturnConsumedCapacity>,
    pub request_items: &'a Option<HashMap<String, KeysAndAttributes>>,
}

Inside the operation impl:

    fn body(&self) -> RestoreTableFromBackupInputBody {
        RestoreTableFromBackupInputBody {
            global_secondary_index_override: &self.global_secondary_index_override,
            local_secondary_index_override: &self.local_secondary_index_override,
            sse_specification_override: &self.sse_specification_override,
            target_table_name: &self.target_table_name,
            backup_arn: &self.backup_arn,
            billing_mode_override: &self.billing_mode_override,
            provisioned_throughput_override: &self.provisioned_throughput_override,
        }
    }
    pub fn build_body(&self) -> String {
        let _ = self.body();
        String::new()
    }

By submitting this pull request, I confirm that you can use, modify, copy, and redistribute this contribution, under the terms of your choice.

[davidbarsky]

What happens if this is null?

[rcoh]

the body is an empty string / empty vec.

[rcoh]

(to clarify, this code isn't the final code, just a placeholder until all the serialization code lands)

Then the body-checking part of the protocol tests will be enabled

[davidbarsky]

If you're not going to handle this now, maybe replace this with unimplmented!()?

[rcoh]

I would normally, but for testing purposes I wanted to actually call this method from the protocol tests and I want the protocol tests to keep passing. Rest assured it will be replaced with real code shortly.

[davidbarsky]

I'm not sure that the return type should be a String. I can imagine several non-UTF-8 inputs and sources; I think that a Vec<u8> can work here?

If not a Vec<u8>, bytes::Bytes?

[rcoh]

that's an interesting thought—I don't have especially strong feelings. Will probably stay away from bytes::Bytes for the moment, although I think we may end up there (or somewhere similar eventually).

My thinking today is that for protocols that are guaranteed to return UTF-8 data, we might as well indicate that. (eg. that way you know these bytes are safe to print, etc.)

[davidbarsky]

Can you leave a comment describing what does .mapNotNull does? Is it a monadic bind?

[rcoh]

it's a kotlin built in that is equivalent to map { xyz }.filter { it != null }