config: add kernel config v4.19.23 for arm64

[Pennyzct]

We add the rough kernel config v4.19.23 for arm64, here we let make oldconfig(setting default) to do the transformation from v4.14.X to v4.19.X.
Former kernel pach 0003-memory-hotplug-by-probe.patch is applied only for v4.14.X, so deleting it here.
We @jongwu will push another PR to land the new 0003-memory-hotplug-by-probe.patch for v4.19.X after runtime/#1111 get merged firstly, since the new patch will broke current CI.
@grahamwhaley @sboeuf

[Pennyzct]

oops, I need to unset all the modules, update asap!

[grahamwhaley]

np, yeah, I see a few =m, but not that many ;-)
l g t m so let me know when you have updated and I'll ack.

[jodh-intel]

We really should consider adding some more tests to:

• https://github.com/kata-containers/packaging/tree/master/.ci

Maybe a check for modules (might be a short-lived check), some sort of kernel config test if a PR changes files under kernel/, etc.

[sboeuf]

@Pennyzct because you removed the patch, the current CI relying on 4.14 will not pass, right?

[Pennyzct]

@sboeuf Noooo~ it's quite the opposite~. The current patch 0003-memory-hotplug-by-probe.patch in the upstream is only applied for v4.14.X, not for v4.19.X.
I'm afraid after runtime/#1111 gets merged, whole guest kernel bumped to v4.19.X, the patch will break down the future v4.19.X CI.
But if I update the patch here in this commit, to make it applied for v4.19.X, then it will not pass and break down the current v4.14.X CI.
So I decide to delete here, to wait for the kernel and CI completely bumped to v4.19.X , and then pull another PR to bring this patch online again.
Hope that I clarify it clearly. ;)

[Pennyzct]

@grahamwhaley updated! all =m gone~ ;)

[grahamwhaley]

/test
thx @Pennyzct !

[sboeuf]

@Pennyzct okay I get it, but that's a chicken and egg problem here. At some point, we will bump the kernel version from the runtime repo but the CI won't pass. And same thing from this PR.
I think a Depends-on might help here. @chavafg wdyt?

[grahamwhaley]

right, chicken and egg. really we could have done with patches having a version match range or something, but that adds more complexity, and @egernst is trying to get us away from that for kernels.
Given the ARM CI has been a bit on/off recently anyway, and we are racing this merge against the 4.19 config update ... I propose we merge this as the first 'step of least pain'...
@sboeuf @egernst - if you agree, let's force this through.

nb. that 16.04 CI fail is afaict unrelated to this PR - we have just seen that on another unrelated item as well.