Speed up builds by fixing github action cache and cargo build cache

[epgts]

• Changes

** Add comments throughout ci.yml explaining how it works.

** Correct path in CARGO_HOME cache.

We were attempting to cache two non-existent directories
/home/postgres/.cargo (~/.cargo). Our actual CARGO_HOME is
/usr/local/cargo, so instead we'll cache those.

** Comment out restore-keys and leave TODO for the plan.

It's not clear why we had so many. The github action cache is write
ONCE, which means over time it becomes colder and colder. We need to
increment the cache keys periodically to warm it back up. When we do
that, we can avoid dropping all the way down to cold cache performance
by moving the previous cacche keys to restore-keys, but it shouldn't
make sense for restore-keys to list more than one previous key.

** Move all commands to new tools/build script.

This both reduces duplication across all the blocks in ci.yml as well as
allowing us to build and test the same way locally.

** Replace sudo with complex and unnecessary flags with su.

Before:
sudo -HEsu postgres sh -c "..."

• -E - preserve environment - su does this already
• -H - force HOME to target user's home directory - su does this already
• -s - run command through shell rather than directly. And then we ran
  ANOTHER shell under that. Both were unnecessary.
• -u postgres - have to specify the user

After:
su postgres -c ...'

** Specify PGVERSION in each job's environment to reduce duplication.

** Run crates tests only once and separate from pgx tests.

These tests do not depend on postgresql so running them more than once
buys us nothing.

Worse, not running the pgx tests under the extension subdirectory causes
pgx to thrash cargo's build cache and build the world twice. We don't
fully understand this, but document what we do know in tools/build.

** TODO Add questions about many of the environment variables.

** TODO Consider running post-install / doc tests separately.

• Timings

Cold cache: 18m20s
https://github.com/timescale/timescaledb-toolkit/runs/5007577229?check_suite_focus=true
Warm cache: 9m14s
https://github.com/timescale/timescaledb-toolkit/runs/5007862209?check_suite_focus=true

[JLockerman]

post-install is testing update scripts, which should be safe to just do once. doc tests are mostly testing continuous aggregates, which I think we want to do on every version 🤔

[epgts]

I haven't looked into the post-install scripts yet. Are you saying they're the same as "update tests"? If so, I misunderstood the conversation yesterday and may have written some incorrect details in #335. In any case, can you add some more details about the post-install, update, and upgrade tests to #335?

[JLockerman]

do you mean ./target? If so, I think that should be safe to use. If we really wanted to be principled, I guess we could try to extract target_directory it from cargo metadata 🤔

[JLockerman]

(users can override the default target directory using a .cargo/config.toml)

[epgts]

I mean .target. I always prefix my build directories with . so I don't trip over them all the time.

I experimented with the setting in ~/.cargo/config.toml and it doesn't seem to be very useful: it overrides for ALL projects and JUST ONE DIRECTORY and resolves it relative to the home directory! Setting build.target-dir = "target" causes /home/epg/target to be used for all Rust builds which works about as well as you'd expect :)

[epgts]

bors r+

[bors]

Build succeeded:

• Clippy Test
• Test PG 12
• Test PG 13
• Test PG 14