always use EC2 node for Builder stage

refs DE-670

For the initial iteration of the EKS project, we’re going to keep the Docker Build process on EC2 in order to avoid using docker-in-docker and its performance implications.

Test Plan
1. use-kubernetes flag continues to use EKS nodes, except for Builder stage which should use EC2
2. normal build continues to use EC2 nodes

[canvas-builds-refspec=c923c731de7a19030fd992ea34cbc47293e4a01d]

Change-Id: Ib7c95ca23e1bd87efcb111a4abbb081ed44f2c2a
Reviewed-on: https://gerrit.instructure.com/c/canvas-lms/+/264667
Tested-by: Service Cloud Jenkins <svc.cloudjenkins@instructure.com>
QA-Review: Aaron Ogata <aogata@instructure.com>
Product-Review: Aaron Ogata <aogata@instructure.com>
Reviewed-by: Andrea Cirulli <andrea.cirulli@instructure.com>

Jenkinsfile

@@ -364,7 +364,7 @@ pipeline {
               buildParameters += string(name: 'CANVAS_LMS_REFSPEC', value: env.CANVAS_LMS_REFSPEC)
             }
 
-            extendedStage('Builder').nodeRequirements(label: 'canvas-docker', podTemplate: libraryResource('/pod_templates/docker_base.yml'), container: 'docker').obeysAllowStages(false).timings(false).queue(rootStages) {
+            extendedStage('Builder').nodeRequirements(label: 'canvas-docker', podTemplate: null).obeysAllowStages(false).timings(false).queue(rootStages) {
               // Use a nospot instance for now to avoid really bad UX. Jenkins currently will
               // wait for the current steps to complete (even wait to spin up a node), causing
               // extremely long wait times for a restart. Investigation in DE-166 / DE-158.