Generate basic Go module with structures

[JordonPhillips]

This adds the ability to generate structure shapes as well as most primitive shapes. Primitives that require imports and specializations of shapes based on traits (e.g. errors / enums) are also not yet supported. Wholly unsupported shape types currently output nil symbols.

The scope of this initial PR was deliberately limited to try to keep its size down, as it already requires a decent amount of infrastructure to get things going.

Currently the following files are generated:

.
├── go.mod
└── api_types.go

The contents of go.mod will look like:

module weather

The base module name here is configurable.

Based on the smithy-go-codegen-test model, the contents of api_types.go will look like:

// Code generated by smithy-go-codegen DO NOT EDIT.
package weather

type CityCoordinates struct {
	Latitude  *float32
	Longitude *float32
}

type CitySummary struct {
	Case   *string
	CityId *string
	Name   *string
	Number *string
}

type GetCityImageInput struct {
	CityId *string
}

type GetCityImageOutput struct {
	Image []byte
}

type GetCityInput struct {
	CityId *string
}

type GetCityOutput struct {
	City        CitySummary
	Coordinates CityCoordinates
	Name        *string
}

type GetCurrentTimeOutput struct {
	Time nil
}

type GetForecastInput struct {
	CityId *string
}

type GetForecastOutput struct {
	ChanceOfRain *float32
}

type ListCitiesInput struct {
	NextToken *string
	PageSize  *int32
}

type ListCitiesOutput struct {
	Items     []CitySummary
	NextToken *string
}

(Note that go fmt is being run on the output)

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

[jasdel]

Minor suggestion for file/folder naming. I think the following pattern will help the SDK breakup go files into smaller chunks making it easier to view source since the files can be so large. e.g. v1 SDK's service/ec2/api.go file is over 100k lines and no longer can be rendered in github. The v2 SDK's equivalent file is about 10k lines.

api_client.go <- generated API client

api_op_Foo.go <- generated Operation method, operation request/response types, and
     operation Input type.  Generated pagination behavior could probably
     go here as well.

api_types.go <- all other struct types

api_enums.go <- all API enums

[jasdel]

It would be helpful for all generated .go files to include the following:

// Code generated toolName DO NOT EDIT.

toolName can be anything, e.g. smithy-go-codegen. Reference, for where this comes from, golang/go#13560 (comment)

General practice is to put it at the top of the file as first line for easier human discovery, but doesn't have to be.

[jasdel]

Don't have to do it ATM but wanted to call out, that it would be good to consider how we'll generate summary/overview documentation API packages.

The package doc string should only appear in one file within a package, (e.g. doc.go file) and provides the documentation/summary/overview of a package. We can determine if this should be a canned string, or incorporate documentation provided by the API model, (e.g v1 sdk's ACM)

// Code generated by smithy-go-codegen DO NOT EDIT.

// Package weather provides the client, and types for the Weather API. <- first paragraph is summary
//
// ... could be more that only appears in API docs overview, not included in package's summary.
package weather

[JordonPhillips]

Eventually we'll add a useFileWriter to GoDelegator, which we'll then use to write out such files. We should include the service shape's documentation there where available.

[kstich]

Can you add a TODO for using inferService from Smithy's codebase instead of just fully removing it?

[JordonPhillips]

To be clear, the intent is to never infer the service.

[jasdel]

assuming specialized strings are enums?

[JordonPhillips]

correct

[JordonPhillips]

and mediatype