Remove Golang dependencies

[webmat]

I'd like to get rid of the dependencies around the Golang ecosystem in this repo.

For this to happen, the following dependencies have to be removed or replaced:

• Remove the legacy Elasticsearch template #629 Remove legacy template
• Remove Go code generator #1567 Remove Go library, it should move to its own repo
• Remove remaining golang dependencies #1585 misspell (either use compiled misspell or use another tool)
• Remove remaining golang dependencies #1585 license check

Reasons why I'd like to remove dependencies on Go:

• Simplify setup for all contributors
• Make it possible for Windows users to run the ECS tooling
• Reduce distractions from supporting 2 languages & related dependencies

[webmat]

@andrewkroh Does "elastic/go-licenser" support looking at more than Go files?

[webmat]

@codebrain thinking about you on this one ;-)

[ruflin]

@webmat Do you plan to make all python based?

Can you elaborate how "Make it possible for Windows users to run the ECS tooling" is related to Golang?

[webmat]

Stuart was unable to run the tooling on Windows, and I think it had to do with Golang. Since I don't know the Go ecosystem and tools very much, I couldn't help him.

I'm pretty sure it was related to Go. Perhaps I'm mis-remembering.

[webmat]

And yes, the goal is to have only Python code in this repo. For simplicity's sake.

I don't mind pulling in compiled binaries like misspell another way, but I want to cut out the dependency on Golang.

[ruflin]

I would assume the Windows issue has more to do with bash scripts than Golang? +1 on removing dependencies but also be aware that it will probably need rewriting of some tooling. And Beats is moving in the opposite direction, getting rid of python and move to Golang. One reason is the cross platform support ;-)

[ebeahan]

Packetbeat is the main consumer of this generated library, and the Beat's module dependencies lists an old version of ECS: v1.8.0.

@andrewstucki @andrewkroh Do you see an eventual need to support a more recent ECS version in this library?

If future versions of Packetbeats will rely on newer versions, we can figure out how to best continue maintaining the library. If we remain pinned to an older version, I'm not sure it's worth investing in continued support or migrating to its own repo.

[andrewstucki]

@ebeahan Personally I'd be fine stripping the library out, if we need updated structures I'm pretty sure we could just check out an old version and use that as a basis for a new library -- as it is there are already some missing things in the current structures that we're actually working around to begin withh. My thought is that we should just strip it out and then migrate to/create a maintained version when we actually need it.