The Billion Dollar Mistake

To be fair, it only happens here because this is a C-style API that was
converted to Go but keeping its general shape. The proper fix, to be
done eventually, is to replace all these boolean error flags by proper
error types.

Fixes #665

github: drop broken semgrep workflow

Revert v2 line length change as discussed in #670

It was clearly a mistake to accept the default formatting change in v2,
and now there's no ideal choice. Either we revert the change and break
some projects twice, or we keep the change and break some projects once.
Given the report comes from Kubernetes, which has a relevant community
and code size, we'll revert it. At the same time, to simplify the life
of those that already started migrating towards the v3 behavior, a new
FutureLineWrap function is being introduced to trivially preserve the
new behavior where desired.

The v3 branch is not affected by this, and will retain the default
non-wrapping behavior. It will also be changed soon to support per
arbitrary line-wrapping for individual encoding operations.

Thanks to everyone who offered code and ideas, and apologies for
the trouble.

Set the default line length to infinity (-1) (#571)

Optimize cases with long potential simple_keys (#555)

This change introduces an index to lookup token numbers referenced by simple_keys in O(1),
thus significantly reducing the performance impact of certain abusively constructed snippets.

When we build up the simple_keys stack, we count on the (formerly named) staleness check to
catch errors where a simple key is required but would be > 1024 chars or span lines. The previous
simplification that searches the stack from the top can go 1024 keys deep before finding a "stale"
key and stopping. I added a test that shows that this consumes ~3s per 1MB of document size.

Fix issue in simple_keys improvements (#548)

Update travis config to use latest go versions (#540)

Fix check for non-map alias merging in v2 (#529)

The problem does not affect v3.

Improve heuristics preventing CPU/memory abuse (#515)

This addresses the following items:

==== Parse time of excessively deep nested or indented documents

Parsing these documents is non-linear; limiting stack depth to 10,000 keeps parse times of pathological documents sub-second (~.25 seconds in benchmarks)

==== Alias node expansion limits

The current limit allows 10,000% expansion, which is too permissive for large documents.

Limiting to 10% expansion for larger documents allows callers to use input size as an effective way to limit resource usage. Continuing to allow larger expansion rates (up to the current 10,000% limit) for smaller documents does not unduly affect memory use.

This change bounds decode operations from alias expansion to ~400,000 operations for small documents (worst-case ~100-150MB) or 10% of the input document for large documents, whichever is greater.

Add logic to catch cases of alias abuse.

Backport of caeefd8.