Clean up of deprecated HttpStart and HttpStop entries

[gberche-orange]

Update following doppler update: no longer returns HttpStart and HttpStop messages

Since cf-release v242, the doppler endpoints no longer return HttpStart and HttpStop messages, in particular in the apps/appid/stream endpoint.

loggregator is No longer supporting message aggregation of HttpStart and HttpStop messages in Metron Agent.

This PR cleans up the deprecated protocol buffer structure and enveloppe objects associated. I would expect the wire lib to ignore these fields in previous versions of doppler protocol (prior to v242). This is part of an attempt to get a fix for recentLogs endpoint #551 (even though only LogMessage events are actually returned in this case)

---

More background:

See announcement at http://cf-dev.70369.x6.nabble.com/cf-dev-Proposal-to-deprecate-the-HttpStart-and-HttpStop-events-tt5507.html

Related dropsonde update cloudfoundry/dropsonde-protocol@3dd1473
and loggregator backlog entry https://www.pivotaltracker.com/n/projects/993188/stories/128893349

[cfdreddbot]

Hey gberche-orange!

Thanks for submitting this pull request! I'm here to inform the recipients of the pull request that you and the commit authors have already signed the CLA.

[cf-gitbot]

We have created an issue in Pivotal Tracker to manage this:

https://www.pivotaltracker.com/story/show/134962371

The labels on this github issue will be updated when the story is started.

[nebhale]

@gberche-orange I'm pretty sure that we can't remove these types for compatibility reasons. Why do you think that removing the types would solve #551?

[gberche-orange]

@nebhale

I'm pretty sure that we can't remove these types for compatibility reasons.

I would think that a newer version of cf-java-client with this PR invoked against an older version of cf (prior to v242) returning HttpStart and HttpStop events would just ignore these fields that have absolute positions in the protocol buffer definition.

I understand this is similar to the cf CLI using the NOA library that indeed bumped the doppler protocol buffer definitions, and AFAIK did not break compatibility

Why do you think that removing the types would solve #551?

Sorry I was ambiguous here. It would not solve the recentLogs issue. I just came across this potential clean up when reproducing the issue 551. Indeed PR 582 is unrelated to issue 551.

[nebhale]

@gberche-orange My compatibility argument is that I'd like to allow a wide-range of Java Client-to-CF compatibility. The API might handle unknown payloads correctly, but if users are pointing at CF versions that still produce those messages legitimately, I think we should allow them through. For better or for worse, we actually implement a bunch of deprecated functionality all of the CAPI API as well.

[gberche-orange]

thanks for the merge Ben.